Zwischenbetriebliche Anwendungsintegration. IT-Management in Unternehmensnetzwerken

Florian Stadlbauer Zwischenbetriebliche Anwendungsintegration

GABLER EDITION WISSENSCHAFT

Florian Stadlbauer

Zwischenbetriebliche Anwendungsintegration IT-Management in Unternehmensnetzwerken

Mit einem Geleitwort von Prof. Dr. Thomas Hess

Deutscher Universitäts-Verlag

Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Dissertation Universität München, 2007 D19

1. Auflage April 2007 Alle Rechte vorbehalten © Deutscher Universitäts-Verlag | GWV Fachverlage GmbH, Wiesbaden 2007 Lektorat: Brigitte Siegel / Britta Göhrisch-Radmacher Der Deutsche Universitäts-Verlag ist ein Unternehmen von Springer Science+Business Media. www.duv.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. 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. Umschlaggestaltung: Regine Zimmer, Dipl.-Designerin, Frankfurt/Main Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier Printed in Germany ISBN 978-3-8350-0751-2

Geleitwort Die Integration von Anwendungssystemen ist ein Themenfeld, das die Wirtschaftsinformatik seit ihrer Entstehung intensiv bearbeitet. Im Mittelpunkt stehen dabei traditionell die konzeptionellen Grundlagen, die Potenziale neuer Technologien und die betriebswirtschaftliche Sinnhaftigkeit der Integration. Eher zögerlich wurde bisher die Frage aufgegriffen, wie die Integration von Anwendungssystemen durch Methoden unterstützt werden kann, obwohl doch die Entwicklung von Methoden in der Forschung zur Softwaretechnik lange Tradition hat. Herr Stadlbauer greift dieses Thema am Beispiel der Unternehmensnetzwerke auf und fokussiert sich auf die frühen Phasen eines Integrationsprojekts. Mit den Unternehmensnetzwerken hat Herr Stadlbauer ein Themenfeld ausgewählt, in dem die Unterstützung durch Anwendungssysteme eine zentrale Rolle spielt und in dem durch nicht-hierarchische Koordinationsformen und vielfältige Spielräume für opportunistisches Verhalten das Management vor besonders großen Herausforderungen steht. Entstanden ist die Arbeit in der Forschungsgruppe NetWorx (Management von Unternehmensnetzwerken) am Institut für Wirtschaftsinformatik und Neue Medien der LMU München und in enger Kooperation mit der Netvolution GmbH, einem Spin-off des Instituts. Die Arbeit umfasst drei wesentliche Abschnitte. In Kapitel 3 stellt Herr Stadlbauer in einem zweistufigen Verfahren heute vorhandene Integrationsmethoden vor und vergleicht diese. Kernstück der Arbeit ist Kapitel vier, in dem Herr Stadlbauer einen eigenen Vorschlag für die Planung und Bewertung von Integrationsvorhaben in Unternehmensnetzwerken vorstellt. Hervorzuheben sind hier insbesondere die elaborierten Vorschläge für einzelne Techniken. In Kapitel 5 präsentiert Herr Stadlbauer die Erfahrungen eines Pilotanwenders seiner Methode mit ausgewählten Teilen der Methoden und gibt damit erste Hinweise auf die Tragfähigkeit seiner Vorschläge. Aus methodischer Perspektive kombiniert Herr Stadlbauer die Konzepte des Method Engineerings mit der sachlogischen Deduktion in einer für die Wirtschaftsinformatik nicht untypischen Form. Method Engineering ist ein Beschreibungsansatz für Methoden, der in den 80er Jahren zunächst im Kontext der Softwareentwicklung entwickelt wurde, später aber auch in weiteren Feldern wie etwa dem Geschäftsprozessmanagement zum Einsatz kam. Die Arbeit überzeugt durch Stringenz in der Argumentation und durch Detailorientierung. Sie sei daher allen Praktikern empfohlen, die konkrete Anhaltspunkte für die Durchführung von Integrationsprojekten suchen. Darüber hinaus liefert die Arbeit aber auch einen wichtigen Beitrag zur Weiterentwicklung des Methodenvorrats der

VI

Geleitwort

Softwareentwicklung. Ich gehe daher davon aus, dass die Arbeit sowohl in der Praxis als auch in der angewandten Wissenschaft auf reges Interesse stoßen wird.

Thomas Hess

Vorwort Seit geraumer Zeit werden Unternehmensnetzwerke als eine der aufstrebenden Organisationsformen der Zukunft gehandelt. Typischerweise wird dies auf ihre signifikanten Kostenvorteile zurückgeführt. Entstehen sollen diese aufgrund der am Netzwerk beteiligten Partnerunternehmen, die sich lediglich auf ihre Kernkompetenzen konzentrieren und sich flexibel, je nach Auftragstyp zusammenfinden. Abhängig sind diese Vorteile jedoch auch von den jeweiligen Geschäftsprozessen, die einem Netzwerk zugrunde liegen. Wie in einer Vielzahl klassischer Unternehmen seit den frühen 1990er Jahren bereits vorzufinden, sind ebenfalls die Prozesse in Netzwerken möglichst effizient auszugestalten. Ein wesentlichen Schlüssel dieser Ausgestaltung liegt in der Integration der am Prozess beteiligten Anwendungssysteme. Nicht zuletzt deshalb wird die Integration in IT-nahen Medien und in der Werbung hoch gehandelt. Verwundern mag allerdings, dass sich kaum spezielle Integrationsansätze für Unternehmensnetzwerke finden. Lediglich reduziert auf Buzzwords, wie „Real time“ und „On Demand”, “Streamlined Processes” oder “Service Oriented Architectures“ bleibt bei den adressierten Netzwerkverantwortlichen vermutlich meist nicht mehr als ein schwer durchschaubares Begriffssammelsurium übrig. Durch den Entwurf und die detaillierte Beschreibung einer netzwerkspezifischen Integrationsmethode – gleichermaßen verankert in der Netzwerkwissenschaft und -praxis – versucht die vorliegende Arbeit Licht in das Dickicht des netzwerkrelevanten Integrationsdschungels zu bringen. Möglich gewesen wäre mir das allerdings nicht ohne die eigene Integration in die unterschiedlichsten Bereiche meines beruflichen und privaten Lebens. So ist an erster Stelle meine Integration am Institut für Wirtschaftsinformatik und Neue Medien der Ludwig-Maximilians-Universität München zu nennen, die mir mein Doktorvater Herr Prof. Dr. Thomas Hess ermöglichte. Dafür und für die zielführende Unterstützung im Rahmen der Entstehung dieser Arbeit möchte ich ihm meinen herzlichen Dank aussprechen. An dieser Stelle sei auch ein großer Dank an meinen Korreferenten Herrn Prof. Dr. Dres. h.c. Arnold Picot übermittelt. Meine Integration in die Forschungsgruppe NetWorx trug ebenfalls im besonderen Maße zur Entstehung dieser Arbeit bei. Danken möchte ich dafür meinem Kollegen Herrn Dr. Stefan Wittenberg, der mir im Rahmen meiner zusätzlichen Integration in das Beratungsunternehmen Netvolution vertiefende Einblicke in die Netzwerkpraxis ermöglichte. Größter Dank gilt ebenfalls Herrn Dr. Christoph Hirnle, meinem langjährigen Bürozimmergenossen und Bescherer einer Reihe von fröhlichen Abenden bzw. Nächten.

VIII

Vorwort

Danke auch an die weiteren (Ex-) Kollegen des Instituts Dr. Lutz Köhler, Dr. Andreas Müller, Dr. Bernhard Gehra, Dr. Alexander Benlian, Renate Schupp Dipl.-Kffr. Barbara Rauscher, Dipl.-Kfm. Benedikt v. Walter, Dipl.-Kfm. Christoph Grau, Dipl.-Kffr. Natalie Kink sowie Dipl.-Kfm. Christian Wolf. In diesem Zuge drängt sich mir allerdings auch die Frage auf, inwiefern der Mensaleitung für die Integration des Kickers in das Mensakonzept für die Entstehung dieser Arbeit zu danken wäre. Für die wertvolle und stets unterhaltsame Integration in meine wöchentliche Doktorandengruppe, deren tatsächlicher Name (DissPro oder ProDiss) mir leider immer noch nicht bekannt ist, bedanke ich mich bei meinen fach- und fußballkundigen Mitstreitern Herrn Dipl.-Kfm. Till Kruse und Herrn Dipl.-Kfm. Christian Wernick. Mein besonderer Dank für die private Integration und damit für die unverzichtbare persönliche und inhaltliche Unterstützung im Rahmen des Entstehungsprozesses der Arbeit gilt meinen Freunden Dipl.-Kfm. Michael Samtleben sowie Dipl.-Kfm. Thomas Wilde. Dazu hat insbesondere die erfolgreiche Integration einer Kaffeemaschine und unzähliger Kekse im Büro von Michael Samtleben beigetragen. Innerhalb meiner familiären Integration möchte ich schließlich meiner Lebensgefährtin Frau Dipl.-Soz. Cornelia Weigand für die unglaubliche und unverzichtbare Unterstützung während des gesamten Entstehungsprozesses der Arbeit ganz herzlich danken. Gleiches gilt für unsere gemeinsame Tochter Sophie Charlotte, die sich am Ende der Entstehung dieser Arbeit in unsere kleine Familie integrierte und mir – ohne dabei ein einziges Wort zu verlieren – bewusst machte, welche Bedeutung Methoden zur Integration in Unternehmensnetzwerken tatsächlich haben. Aber dies mag jeder für sich selbst auf den folgenden Seiten herausfinden.

Florian Stadlbauer

Inhaltsübersicht Abbildungsverzeichnis ..............................................................................................XV Abkürzungsverzeichnis............................................................................................XIX 1 Einführung .............................................................................................................. 1 2 Grundlagen und Methodenanforderungen ........................................................... 13 3 Untersuchung bestehender Integrationsmethoden............................................... 79 4 Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken...................................................................................121 5 Evaluation der Integrationsmethode....................................................................221 6 Schlussbetrachtung.............................................................................................235 Literaturverzeichnis .................................................................................................241

Inhaltsverzeichnis Abbildungsverzeichnis ..........................................................................................XV Abkürzungsverzeichnis ........................................................................................XIX 1 Einführung ............................................................................................................ 1 1.1 Problemstellung ............................................................................................. 1 1.2 Stand der Forschung und Forschungsdefizit ................................................. 3 1.3 Zielsetzung und Methodik .............................................................................. 5 1.4 Aufbau und Entstehungskontext der Arbeit.................................................... 9 2 Grundlagen und Methodenanforderungen........................................................13 2.1 Grundlegende Begriffe................................................................................. 13 2.1.1 Unternehmensnetzwerke .................................................................. 13 2.1.1.1 Kooperationen zwischen Markt und Hierarchie als Ausgangspunkt .................................................................. 13 2.1.1.2 Netzwerke als zwischenbetriebliche Kooperation .............. 16 2.1.1.3 Formen und Ausgestaltung von Netzwerken ..................... 20 2.1.2 Zwischenbetriebliche Anwendungssystemintegration ....................... 23 2.1.2.1 Anwendungssysteme als Ausgangspunkt.......................... 23 2.1.2.2 Grundlagen der Integration ................................................ 27 2.1.2.3 Netzwerkspezifische Integrationsarchitekturen .................. 32 2.1.3 Method Engineering als Analyseansatz ............................................ 40 2.2 Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken........... 44 2.2.1 Fallstudienauswahl und Analysevorgehen ........................................ 45 2.2.2 Fallstudienanalyse............................................................................. 47 2.2.2.1 Daten-Sharing bei Biege 21 ............................................... 47 2.2.2.2 Applikations-Kommunikation in einem Vertriebsnetzwerk.. 53 2.2.2.3 Eigenentwickeltes Applikations-Sharing bei KFS............... 58 2.2.2.4 Standardisiertes Applikations-Sharing bei VisQuaNet ....... 63 2.2.3 Gegenüberstellung der Fallstudien.................................................... 66 2.3 Ableitung netwerkspezifischer Methodenanforderungen ............................. 71 3 Untersuchung bestehender Integrationsmethoden .........................................79 3.1 Bestehende Integrationsmethoden im Überblick ......................................... 79

XII

Inhaltsverzeichnis

3.1.1 Zur Auswahl der Integrationsmethoden............................................. 79 3.1.2 Charakteristika der Integrationsmethoden......................................... 81 3.2 Detaillierte Analyse ausgewählter Integrationsmethoden ............................ 92 3.2.1 FORWIN-Ansatz................................................................................ 92 3.2.2 ARIS-Ansatz...................................................................................... 96 3.2.3 St. Galler Ansatz ..............................................................................101 3.2.4 Emmelhainz-Ansatz .........................................................................106 3.3 Zusammenfassende Bewertung der analysierten Integrationsmethoden ...112 3.3.1 Gegenüberstellung ...........................................................................112 3.3.2 Beurteilung der Integrationsmethoden .............................................117 4 Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken................................................................................121 4.1 Eckpfeiler der Methode ...............................................................................121 4.2 Metamodell .................................................................................................124 4.2.1 Sicht „Integrationsbereich“ ...............................................................124 4.2.2 Sicht „Integrationslösung“.................................................................125 4.3 Vorgehensmodell ........................................................................................126 4.4 Techniken ...................................................................................................128 4.4.1 Ermittlung der Netzwerkprozessorganisation ...................................129 4.4.1.1 Ansatz ...............................................................................129 4.4.1.2 Vorgehen ..........................................................................136 4.4.2 Identifikation der Integrationsbereiche..............................................145 4.4.2.1 Ansatz ...............................................................................145 4.4.2.2 Vorgehen ..........................................................................149 4.4.3 Evaluation der Integrationsbereiche .................................................156 4.4.3.1 Ansatz ...............................................................................156 4.4.3.2 Vorgehen ..........................................................................159 4.4.4 Integrationsspezifikation ...................................................................170 4.4.4.1 Ansatz ...............................................................................170 4.4.4.2 Vorgehen ..........................................................................177 4.4.5 Integrations-Assessment ..................................................................194 4.4.5.1 Ansatz ...............................................................................194

Inhaltsverzeichnis

XIII

4.4.5.2 Vorgehen ..........................................................................199 4.5 Ergebnismodell ...........................................................................................209 4.6 Rollenmodell ...............................................................................................213 4.6.1 Netzwerkspezifische Besonderheiten...............................................213 4.6.2 Rollen innerhalb von Integrationsprojekten in Netzwerken...............215 5 Evaluation der Integrationsmethode ...............................................................221 5.1 Einführung in das Fallbeispiel zur Methodenevaluation ..............................221 5.2 Methodenergebnisse aus dem Fallbeispiel.................................................222 5.3 Kritische Würdigung der Methode...............................................................230 6 Schlussbetrachtung..........................................................................................235 6.1 Zusammenfassung der zentralen Ergebnisse.............................................235 6.2 Kritische Würdigung und weiterer Forschungsbedarf .................................238 Literaturverzeichnis ..............................................................................................241

Abbildungsverzeichnis Abb. 1.3/1: Abb. 1.4/1:

Systematisierung der Forschungsziele der Untersuchung ...............7 Aufbau der Arbeit............................................................................10

Abb. 2.1.1.1/1: Abb. 2.1.1.2/1: Abb. 2.1.1.2/2:

Transaktionskosten bei gegebener Spezifität .................................15 Grundformen der betrieblichen Kooperation...................................17 Charakteristika der Grundtypen zwischenbetrieblicher

Abb. 2.1.1.3/1: Abb. 2.1.1.3/2:

Kooperation ....................................................................................19 Idealtypische Grundvarianten von Unternehmensnetzwerken........21 Zwei-Ebenen-Architektur von Unternehmensnetzwerken...............22

Abb. 2.1.2.1/1: Abb. 2.1.2.1/2: Abb. 2.1.2.2/1:

Abgrenzung von Anwendungssystemen ........................................26 Anwendungssysteme und ihre Ziele in Unternehmensnetzwerken 27 Integration von Anwendungssystemen...........................................29

Abb. 2.1.2.2/2: Abb. 2.1.2.3/1:

Integrationsmerkmale zur Übersicht ...............................................31 Grundlegende Integrationsarchitekturen für Unternehmensnetzwerke................................................................32

Abb. 2.1.2.3/2: Abb. 2.1.2.3/3: Abb. 2.1.2.3/4:

Zentrale Datenbank zum Daten-Sharing ........................................34 Punkt-zu-Punkt-Integration zur Applikations-Kommunikation .........36 Middleware-basierte Integrationstechnologien zur Applikations-

Abb. 2.1.2.3/5:

Kommunikation...............................................................................38 Integrierte Anwendungssysteme und WebServices zum Applikations-Sharing.......................................................................40

Abb. 2.1.3/1: Abb. 2.1.3/2: Abb. 2.1.3/3:

Anwendungsgebiete des Method Engineering ...............................42 ER-Diagramm zur Abbildung eins Metamodells .............................44 Komponenten des Method Engineerings........................................44

Abb. 2.2.1/1: Abb. 2.2.1/2: Abb. 2.2.2.1/1:

Ausgangslagen und Zielsetzungen innerhalb der Fallstudien ........46 Raster zur Methodenbeschreibung.................................................47 Metamodell der Biege-Integration...................................................50

Abb. 2.2.2.1/2: Abb. 2.2.2.2/1: Abb. 2.2.2.3/1:

Typische Gliederungspunkte eines Pflichtenhefts ..........................52 Metamodell der Integration des Vertriebsnetzwerks.......................55 Metamodell der KFS-Integration.....................................................60

Abb. 2.2.2.4/1: Abb. 2.2.3/1: Abb. 2.2.3/2:

Metamodell der VisQuaNet-Integration ..........................................65 Verfeinertes Raster zur Gegenüberstellung der Integrationsmethoden.....................................................................67 Gestaltungsfelder der Integrationslösungen der Fallbeispiele ........68

Abb. 2.2.3/3: Abb. 2.3/1: Abb. 2.3/2:

Gegenüberstellung der Fallbeispiele ..............................................71 Kernaktivitäten des Integrationsvorgehens.....................................73 Anordnungsvarianten der Kernaktivitäten für die Integration ..........73

XVI

Abbildungsverzeichnis

Abb. 2.3/3:

Anforderungen an das Aktivitätenmodell ........................................74

Abb. 2.3/4:

Anforderungen an die zu enthaltenden Techniken der Integrationsmethode.......................................................................75 Steigender Detaillierungsgrad der Techniken.................................76 Zusammenfassung der Methodenanforderungen...........................77

Abb. 2.3/5: Abb. 2.3/6: Abb. 3.1.1/1: Abb. 3.1.2/1: Abb. 3.1.2/2:

Ermittelte Integrationsmethoden.....................................................80 Zusammenfassung der inhaltlichen und strukturellen Übereinstimmungen .......................................................................90 Gegenüberstellung der Methoden ..................................................91

Abb. 3.2.1/1:

Metamodell der FORWIN-Integrationsmethode..............................93

Abb. 3.2.2/1: Abb. 3.2.2/2:

ARIS-Architektur.............................................................................97 ARIS-Metamodell ...........................................................................98

Abb. 3.2.3/1:

Ebene des St. Galler Informationssystemmanagements ..............101

Abb. 3.2.3/2: Abb. 3.2.3/3:

Metamodell der St. Galler Integrationsmethode ...........................102 Rollenmodell der St. Galler Integrationsmethode .........................106

Abb. 3.2.4/1: Abb. 3.2.4/2: Abb. 3.3.1/1:

Metamodell der Integrationsmethode nach Emmelhainz ..............107 Organigramm eines EDI-Projektteams nach Emmelhainz............111 Berücksichtigte Aktivitäten der Methoden.....................................113

Abb. 3.3.1/2:

Methodische Unterstützung zur Identifizierung von Integrationsbereichen ...................................................................115

Abb. 3.3.1/3: Abb. 3.3.2/1: Abb. 4.2.1/1:

Gegenüberstellung der Integrationsmethoden..............................117 Beurteilung der untersuchten Integrationsmethoden ....................119 Metamodell der Sicht „Integrationsbereiche“ ................................125

Abb. 4.2.1/2: Abb. 4.3/1: Abb. 4.4/1:

Metamodell der Sicht „Integrationslösung“ ...................................126 Vorgehensmodell..........................................................................127 Techniken und ihre zentralen Ergebnisse ....................................129

Abb. 4.4.1.1/1: Abb. 4.4.1.1/2: Abb. 4.4.1.1/3:

Starre und flexible Konfiguration der Auftragsbearbeitung ...........130 Schritte im Zielbildungsprozess ....................................................134 Angepasstes Analyse-Synthese-Schema.....................................136

Abb. 4.4.1.2/1:

Vorgehensschritte und Ergebnisdokumente zur Ableitung der Netzwerkprozessorganisation.......................................................137 Zielrelationsmatrix zur Ermittlung der Zielverträglichkeit ..............139 Relevanzbeurteilung der Ziele ......................................................140

Abb. 4.4.1.2/2: Abb. 4.4.1.2/3: Abb. 4.4.1.2/4: Abb. 4.4.1.2/5: Abb. 4.4.1.2/6: Abb. 4.4.2.1/1:

Rangordnungssumme zur Ermittlung der Zielgesamtunterstützung ..............................................................140 Beurteilung der Prozessrelevanz..................................................143 Netzwerkprozess-Organisations-Diagramm .................................145 Anwendungssystemarchitektur nach dem Business System Planning........................................................................................148

Abbildungsverzeichnis

XVII

Abb. 4.4.2.2/1:

Vorgehensschritte und Ergebnisdokumente zur

Abb. 4.4.2.2/2: Abb. 4.4.2.2/3: Abb. 4.4.2.2/4:

Integrationsbereichsidentifikation .................................................150 Anwendungssystem-Landkarte zur Systemerfassung..................151 Vereinfachte System-Prozess-Matrix ...........................................152 Input-Process-Output-Analyse......................................................153

Abb. 4.4.2.2/5: Abb. 4.4.2.2/6: Abb. 4.4.3.2/1:

Erfassung der Informationsflüsse im Netzwerk.............................154 Detailanalyse der Kommunikationsbeziehung ..............................155 Vorgehensschritte und Ergebnisdokumente zur Evaluation der Integrationsbereiche .....................................................................159

Abb. 4.4.3.2/2:

Berechnung der geschätzten durchschnittlichen Priorisierung

Abb. 4.4.3.2/3:

eines Erfolgsfaktors auf Netzwerkebene ......................................161 Mögliche Skala zur Einschätzung der Priorität und Leistung eines Erfolgfaktors .................................................................................161

Abb. 4.4.3.2/4:

Ermittlung der relativen Bedeutung eines Erfolgsfaktors auf Netzwerkebene.............................................................................162

Abb. 4.4.3.2/5: Abb. 4.4.3.2/6: Abb. 4.4.3.2/7:

Bewertung der Zielunterstützung der Integrationsbereiche ..........163 Matrix zur Beurteilung des Integrationsbedarfs ............................164 Teilportfolio „Integrationsbedeutung“ ............................................165

Abb. 4.4.3.2/8: Abb. 4.4.3.2/9:

Aspekte zur Ermittlung der Integrationsrisiken .............................166 Ergebnismatrix zur Risikoeinschätzung der Integrationsbereiche

auf Netzwerkebene.......................................................................167 Abb. 4.4.3.2/10: Aspekte zur Beurteilung des Nutzens einer integrierten Lösung ..168 Abb. 4.4.3.2/11: Teilportfolio „Integrationsattraktivität“............................................168 Abb. 4.4.3.2/12: Kombinations-Portfolio der Integrationsbereichsevaluation ..........169 Abb. 4.4.4.1/1: Systematisierung nicht-funktionaler Anforderungen nach Sinz.....172 Abb. 4.4.4.1/2: Aktivitäten der Anforderungsermittlung.........................................174 Abb. 4.4.4.2/1: Abb. 4.4.4.2/2: Abb. 4.4.4.2/3: Abb. 4.4.4.2/4: Abb. 4.4.4.2/5: Abb. 4.4.4.2/6: Abb. 4.4.4.2/7: Abb. 4.4.4.2/8: Abb. 4.4.5.2/1:

Vorgehensschritte und Ergebnisdokumente der Integrationsspezifikation ...............................................................177 Typische Szenarien zur Bestimmung der Integrationsarchitektur.179 Abstrakte Klassen indirekter Viewpoints.......................................181 Anforderungsermittlung anhand der Ist-Situation und dem Integrationsziel .............................................................................184 Merkmale zur Identifikation nicht-funktionaler Anforderungen ......186 Anforderungsformular zur Überprüfung der vollständigen Erfassung .....................................................................................188 Priorisierung der Anforderungen...................................................191 Gliederungsschema der Anforderungsspezifikation .....................192 Vorgehensschritte und Ergebnisdokumente des IntegrationsAssessment ..................................................................................199

XVIII

Abbildungsverzeichnis

Abb. 4.4.5.2/2:

Kostenkategorien und Messgrößen des TCO-Ansatzes...............201

Abb. 4.4.5.2/3: Abb. 4.4.5.2/4: Abb. 4.4.5.2/5:

Ermittlung des Gesamtnutzens aus den individuellen Nutzenerfassungen ......................................................................204 Portfolio zur Erfassung der Investitionsrisiken ..............................206 Formel zur Kapitalwertberechnung...............................................206

Abb. 4.5/1: Abb. 4.5/2: Abb. 4.5/3: Abb. 4.5/4:

Ergebnisdokumente zur Ermittlung der Netzwerkorganisation .....210 Ergebnisdokumente zur Identifikation der Integrationsbereiche ...211 Ergebnisdokumente zur Evaluation der Integrationsbereiche ......212 Ergebnisdokumente zur Integrationsspezifikation ........................212

Abb. 4.5/5:

Ergebnisdokumente des Integrations-Assessments.....................213

Abb. 4.6.1/1:

Projektbeteiligte mit mehreren Rollen im Rahmen des Integrationsvorgehens ..................................................................214

Abb. 4.6.1/2:

Varianten der Organisation von Integrationsprojekten..................215

Abb. 4.6.2/1:

Rollenmodell für Integrationsplanung und -bewertung in Netzwerken...................................................................................217

Abb. 5.2/1: Abb. 5.2/2: Abb. 5.2/3:

Informationsfluss des Prozesses Data-Management ...................225 Detailanalyse der ausgewählten Kommunikationsbeziehungen ...225 Beurteilung der Ist-Situation zur Anforderungsermittlung .............228

Abkürzungsverzeichnis ARIS

Architektur Integrierter Informationssysteme

AS

Anwendungssystem

CIM

Computer Integrated Manufacturing

CRM

Customer Relationship Management

DB

Datenbank

DLR

Deutsches Zentrum für Luft- und Raumfahrt e.V.

EAI

Enterprise Application Integration

EDI

Electronic Data Interchange

EPK

Ereignisgesteuerte Prozesskette

ERM

Entitiy Relationship Modell

ETL

Extraction, Transformation, Loading

FORWIN

Bayerischer Forschungsverbund Wirtschaftsinformatik

GbR

Gesellschaft bürgerlichen Rechts

IKT

Informations- und Kommunikationstechnologien

IP

Internet Protocol

IS

Informationssystem

IT

Informationstechnologie

KEF

Kritische Erfolgsfaktoren

KFS

Kooperationsverbund Fertigung Südthüringen

MIS

Management Informationssysteme

MRP

Material-Requirements-Planning

MTT

Mikrotechnik Thüringen e.V.

OEM

Original Equipment Manufacturer

PPS

Produktionsplanung- und Steuerung

ROI

Return on Investment

SMTP

Simple Mail Transport Protocol

TCP

Transmission Control Protocol

WI

Wirtschaftsinformatik

XML

Extensible Markup Language

Streamlining cross-company process is the next great frontier for reducing cost, enhancing quality, and speeding operations.

Michael Hammer1

1 Einführung 1.1

Problemstellung

Heutige Unternehmen kennzeichnet vermehrt ein steigender Automatisierungsgrad ihrer betrieblichen Prozesse. Treiber hierfür sind vor allem die veränderten betrieblichen Anforderungen hin zu prozessorientierten Verfahren und verkürzten Reaktionszeiten sowie der zunehmende Technologiedruck. Damit verbunden ist die zunehmende Verbreitung innovativer Informations- und Kommunikationstechnologien (IKT) und demzufolge auch von Anwendungssystemen.2 Der massive Einsatz unterschiedlicher Anwendungssysteme ist daher aus dem betrieblichen Alltag kaum mehr wegzudenken. Jedoch birgt die zunehmende Anwendungssystemunterstützung typischerweise kosten- und zeitintensive Medienbrüche zwischen interdependenten Systemen. Ein bedeutender Schlüssel für den Umgang mit diesen Problemfeldern liegt in der Etablierung reibungsloser Informationsflüsse durch die Anwendungssystemintegration.3 Keinesfalls ist die Nutzung von IKT jedoch auf den innerbetrieblichen Kontext beschränkt. Vielmehr dient sie Unternehmen bereits seit geraumer Zeit ebenfalls zur Verbesserung der zwischenbetrieblichen Zusammenarbeit und führt damit mitunter zu tief greifenden strukturellen Umbrüchen. So unterstützt die moderne IKT unter anderem die zunehmende Bildung gänzlich neuer Organisationsformen mit netzwerkartigen Strukturen.4 Kennzeichen dieser meist als Unternehmensnetzwerke bezeichneten Organisationsformen ist die Bildung eines Pools aus mindestens drei rechtlich und wirtschaftlich selbständigen Partnerunternehmen, die sich für die Auftragsabwicklung flexibel und je nach Auftragsart zusammenfinden.5 Nicht zuletzt lassen sich im Rahmen dieser netzwerkartigen Strukturen signifikante Kostenvorteile erzielen, da sich die beteiligten Partner eines Netzwerks typischerweise lediglich auf ihre Kernkompetenzen konzentrieren.6 1 2 3 4 5 6

Hammer (2001), S. 83. Vgl. Fleisch/Österle (2004), S. 5; Mertens et al. (2005), S. 6. Vgl. Müller (2005), S. 30-31; Scheckenbach (1997), S.1; Heilmann (1989), S. 47-48. Vgl. Hess (2002a), S. 1; Odendahl (2001), S. 72-73; Pribilla (2000), S. 2; Klein (1996), S. 22-27. Vgl. Wohlgemuth (2002), S. 18. Vgl. Schräder (1996), S. 56. Ähnlich Wang et al. (2004), S. 76-77. Fehlende Kompetenzen werden je nach Bedarf durch die weiteren Partnerunternehmen beigesteuert.

2

Einführung

Grundsätzlich agieren Unternehmensnetzwerke auf den gleichen Märkten wie klassische Unternehmensformen und treten dabei trotz der losen Strukturen nach außen hin meist geschlossen auf.7 Entsprechend haben sie sich ebenfalls den skizzierten veränderten betrieblichen Anforderungen sowie dem Technologiedruck zu stellen. Führten die beiden Aspekte im Rahmen des innerbetrieblichen Kontextes zu vielfältigen Automatisierungsbestrebungen der unternehmensinternen Prozesse, so liegen die überbetrieblichen Prozesse selten in vergleichbar automatisierter Form vor.8 Ohne die effektive Durchführung der überbetrieblichen Prozesse riskieren die Netzwerke jedoch ihre Kostenvorteile und damit die Möglichkeit, erfolgreich auf den umkämpften Märkten zu bestehen. In Anlehnung an die oben skizzierten klassischen Unternehmen können Unternehmensnetzwerke diesen Problemfeldern mit einer zwischenbetrieblichen Anwendungssystemintegration begegnen.9 Birgt die Komplexität der Etablierung einer integrierten Informationsverarbeitung im innerbetrieblichen Kontext schon eine Vielzahl von Problemen und Risiken,10 so ist die Integration im netzwerkspezifischen Kontext ungleich schwerer einzuschätzen. Hintergrund ist nicht zuletzt die im Netzwerk anzutreffende unverbindliche Zusammenarbeit der Partner und die damit verbundene fehlende Bereitstellung umfangreicher Ressourcen. Ebenfalls spielt hierbei die rechtliche und wirtschaftliche Selbständigkeit eine Rolle, die eine Weisungsmöglichkeit der Partnerunternehmen weitgehend ausschließt. Schließlich stellt die im Vergleich zum innerbetrieblichen Kontext zu erwartende höhere Heterogenität der IT-Infrastruktur in Netzwerken einen bedeutenden Problembereich dar. Vor dem Hintergrund des Bedarfs einer integrierten Informationsverarbeitung für die erfolgreiche Arbeit der Netzwerke und den skizzierten Problemen, die bei ihrer Etablierung im netzwerkspezifischen Kontext zu erwarten sind stellt sich die Frage, wie Unternehmensnetzwerke grundsätzlich bei der Integration vorgehen sollten. Da Lösungen für technische Fragen der inner- und ebenfalls zwischenbetrieblichen Integration weitgehend vorangeschritten sind11 ist insbesondere zu klären, inwiefern das Integrationsmanagement, unter dem die Planung und Bewertung von Integrationsprojekten zusammengefasst wird, an die Besonderheiten netzwerkartiger Organisationsformen anzupassen ist.

7 8 9 10

11

Vgl. etwa Alt et al. (2005), S. 9; Albers et al. (2003), S. 9. Vgl. Hammer (2001), S. 82; Schulze/Koller (2002), S. 115. Vgl. Mantel et al. (2004), S. 21-22; Scheckenbach (1997), S. 23-27. Hintergrund sind dabei meist die Heterogenität der betroffenen Anwendungssysteme, unvereinbare Datendefinitionen sowie Mauern und Gräben zwischen den betroffenen Bereichen eines Unternehmens (vgl. Schulze/Koller (2002), S. 115). Vgl. Fleisch (2001), S. 127-128.

Stand der Forschung und Forschungsdefizit

3

Neben der bisher vorgestellten Relevanz des Themas innerhalb der Praxis zeigt sich gleichermaßen dessen besondere Bedeutung innerhalb der Forschung, und dort insbesondere in der Wirtschaftsinformatik. Dies zeigt eine 1999 durchgeführte Befragung von 30 Wirtschaftsinformatikern, Wirtschaftswissenschaftlern sowie hochrangigen Vertretern aus der Praxis nach den zukünftigen Erkenntniszielen der Wirtschaftsinformatik im Zehnjahreszeitraum.12 Von hervorzuhebendem Interesse ist gemäß der Befragung insbesondere die „Schaffung verbesserten Wissens über die Beherrschung von Komplexität in Informations- und Kommunikationssystemen“ (Rang 1) sowie die „Schaffung verbesserten Wissens über Netzmärkte und virtuelle Märkte“ (Rang 2).13 Die innerhalb des Problemfelds der vorliegenden Untersuchung fest verankerten Kernbereiche zum einen der „Integration“, welche insbesondere der Komplexitätsbeherrschung von IKT dient, sowie zum anderen der „Unternehmensnetzwerke“, welche den Themenkomplex der Netz- und virtuellen Märkten tangieren, unterstreichen die Relevanz dieser Untersuchung innerhalb der wissenschaftlichen Forschung. 1.2

Stand der Forschung und Forschungsdefizit

Gemäß dem aufgezeigten Untersuchungsgegenstand in Form des Integrationsmanagements in Unternehmensnetzwerken sind insbesondere die Forschungsfelder der Unternehmensnetzwerke sowie der Integration betroffen. Im Folgenden wird ein kurzer Überblick über die Entwicklung sowie den aktuellen Stand dieser beiden Forschungsfelder gegeben. Die ersten Ansätze im Forschungsfeld zu Unternehmensnetzwerken gehen auf das Ende der 1980er, Anfang der 1990er Jahre zurück.14 Im Mittelpunkt dieser insbesondere durch die betriebswirtschaftliche Forschung sowie die Wirtschaftsinformatik vorangetriebenen Beiträge stand zunächst die theoretische Fundierung möglicher Entstehungsgründe von Unternehmensnetzwerken. Wesentliche Beiträge zur Erklärung der Netzwerkentstehung lieferten seither insbesondere die Transaktionskostentheorie, der ressourcenbasierte Ansatz, die Systemtheorie verbunden mit der kybernetischen Theorie, sowie spieltheoretische Ansätze.15 Neben dieser ersten, stark theoretisch geleiteten Bemühung hinsichtlich der Aufarbeitung des Forschungsfelds „Netzwerke“ entstand etwa zur gleichen Zeit eine Reihe von Arbeiten, die sich überwiegend mit der organisatorischen und technischen Aus12 13 14 15

Damit ausgehend vom Jahre 1999 bis etwa zum Jahre 2009. Vgl. Heinzl et al. (2001), S. 230. Vgl. Wohlgemuth/Hess (2001). Vgl. zur Übersicht etwa Wang et al. (2004); Sydow (1992), S. 127-235 oder im Detail etwa die Arbeiten von Powell (1990); Rotering (1990); Wolff/Neuburger (1995) sowie Steven/Otterpohl (2000).

4

Einführung

gestaltung von Netzwerken befassten. Der wesentliche Beitrag dieser Arbeiten liegt zum einen in der Erarbeitung von Lösungsvorschlägen zur Regulierung und Ausgestaltung der dezentralen Arbeitsteilung16 sowie insbesondere in den Erklärungs- und Gestaltungsansätzen einer informationstechnischen Unterstützung der Unternehmensnetzwerke.17 Ergänzt werden diese beiden Forschungsbemühungen etwa seit dem Jahr 2000 durch Ansätze zum Management bzw. Controlling in Netzwerken. Der Fokus dieser Arbeiten liegt zu großen Teilen in der Entwicklung sowie Anpassung von Managementinstrumenten, die sich speziell für den Einsatz in Netzwerken eignen.18 Zielten die ersten Arbeiten zum Netzwerkmanagement typischerweise auf übergeordnete Managementaufgaben, wie etwa die Steuerung der Aufträge bzw. der Partner des Netzwerks,19 so rückt seit jüngerer Zeit – wenn auch noch zögerlich – das Informationsmanagement in Netzwerken in den Betrachtungsfokus der Netzwerkforschung.20 Jedoch finden sich in den Arbeiten zum Informationsmanagement in Netzwerken keine Hinweise zum Vorgehen für die Integration in Netzwerken. Neben den Unternehmensnetzwerken bildet das überwiegend von der Wirtschaftsinformatik geprägte Forschungsfeld der Anwendungssystemintegration Ansatzpunkte für die Bearbeitung des oben skizzierten Untersuchungsgegenstands. Im Kern lässt sich das Forschungsfeld in drei Phasen gliedern, wovon die erste Phase bereits auf die 1960er Jahre zurückgeht.21 Dabei lag der Forschungsfokus auf der Bedeutung und Ausgestaltung zunächst proprietärer sowie später standardisierter Schnittstellen für die inner- und zwischenbetriebliche Punkt-zu-Punkt Verknüpfung von Anwendungssystemen zur Datenübertragung.22 Nicht zuletzt die Erkenntnis über die zunehmende Komplexität der durch eine Vielzahl von Punkt-zu-Punkt-Verbindungen integrierten Anwendungssystemlandschaften innerhalb und zwischen Unternehmen führte in den 1990ern zur zweiten bedeutenden Phase der Forschungsarbeiten zur Integration. Im Vordergrund stand dabei insbesondere der Austausch der heterogenen Anwendungssystemlandschaft eines Unternehmens durch monolithische bzw. in Module unterteilte Systeme, verbunden mit

16 17

18

19 20 21 22

Vgl. etwa Sydow (1995); Specht/Kahmann (2000) oder Kemmner/Gillessen (2000). Stellvertretend die Arbeiten von Servatius (1987); Rupprecht-Däullary (1994); Arnold et al. (1995); Klein (1996) oder Mertens et al. (1998). Vgl. etwa die ersten Vorarbeiten von Schräder (1996); Hippe (1997) sowie die Arbeiten von Hess (2002a); Wohlgemuth (2002); Sydow (2003) oder Albers et al. (2003). Vgl. zu allgemeinen Managementaufgaben in Netzwerken Hess (2002a), S. 18-21. Vgl. etwa die Arbeit von Hirnle (2006) oder Katzy (2005). Vgl. Schönherr/Gallas (2003), S. 126-128; Heilmann (1989), S. 53. Vgl. etwa die Arbeiten von Mertens (1966); Grochla (1974); Monczka/Carter (1988); Holland/Lockett (1992) oder Fischer (1993).

Zielsetzung und Methodik

5

einer möglichst unternehmensweit einheitlichen Datenbasis.23 Die Praxis zeigte jedoch die mit dem Einsatz großintegrierter Systeme verbundenen Schwierigkeiten auf, die im Kern in der Etablierung einer einzigen unternehmensweiten Datenbasis lagen und dem Versuch, sämtliche Funktionen innerhalb eines einzelnen Systems bereitzustellen.24 Die Erkenntnisse über die Nachteile großintegrierter Anwendungssysteme führten zu Beginn des 21. Jahrhunderts zu einer weiteren Phase innerhalb der Integrationsforschung, die bis in die heutige Zeit anhält. So stehen etwa unter den Stichworten der Enterprise Application Integration (EAI) oder WebServices derzeit vor allem flexible Architekturen im Vordergrund, die – etwa durch die Bereitstellung einer zentralen Integrationsplattform – eine effiziente Kopplung der unternehmensinternen oder externen Systeme ermöglichen.25 Innerhalb der drei wesentlichen Forschungsphasen zur Integration finden sich ebenfalls vereinzelt Hinweise für ein methodisches Vorgehen, um die jeweilige Integration zu erreichen.26 Auch, wenn sich darunter Arbeiten finden, die sich mit der Integration im zwischenbetrieblichen Kontext auseinandersetzen,27 konnte kein Beitrag identifiziert werden, der sich mit den netzwerkspezifischen Besonderheiten befasst und damit ein konkretes Integrationsvorgehen für Netzwerke enthält. Vor dem Hintergrund der vom Untersuchungsgegenstand betroffenen Forschungsfelder kann somit ein „Forschungsdefizit“ hinsichtlich methodischer Hinweise für die Anwendungssystemintegration in Unternehmensnetzwerken festgestellt werden. 1.3

Zielsetzung und Methodik

Ausgehend vom skizzierten Forschungsdefizit liegt das Ziel der vorliegenden Arbeit in der Aufarbeitung des Themenkomplexes der Integrationsmethode für Unternehmensnetzwerke. Aufgrund des in der Zielsetzung enthaltenen starken Bezugs zur Ausgestaltung von Anwendungssysteminfrastrukturen ist sie hinsichtlich der davon betroffenen Forschungsdisziplin insbesondere der Wirtschaftsinformatik zuzuordnen. Allgemein verfolgt die Wirtschaftsinformatik mit dem Erkenntnis- sowie Gestaltungsziel zwei Forschungsaufträge.28 Zielt das Erkenntnisziel der Wirtschaftsinformatik zu23

24 25 26

27 28

Vgl. etwa die Arbeiten von Scheer (1991); Schumann (1992) oder Kumar/van Hillegersberg (2000). Vgl. Kaib (2002), S. 56. Stellvertretend die Arbeiten von Ring (2000); Keller (2002) oder Reichmayr (2003). Vgl. die Arbeiten von Emmelhainz (1990) für die Punkt-zu-Punkt-Integration; Scheer (1998) für großintegrierte Anwendungssystem sowie Linthicum (2000) für die Integration mittels flexiblen Architekturen. Vgl. etwa Mantel et al. (2004). Vgl. Mertens et al. (2005), S. 3.

6

Einführung

nächst auf das Verstehen gegebener Phänomene, so verfolgt das Gestaltungsziel die Gestaltung neuer Sachverhalte. Übertragen auf die angestrebte Integrationsmethode ergibt sich als Erkenntnisziel allgemein das Verständnis von Methoden zur Integration sowie als Gestaltungsziel die tatsächliche Methodenentwicklung.29 In Anlehnung an die allgemeinen Zielsetzungen der Wirtschaftsinformatik lässt sich die übergeordnete Zielsetzung der vorliegenden Arbeit in drei Teilziele differenzieren. Wie bereits bei der Aufarbeitung des Stands der Forschung zu Integrationsmethoden für Unternehmensnetzwerke aufgezeigt, finden sich derzeit keine Erkenntnisse, die sich diesem Untersuchungsbereich widmen. Entsprechend lässt sich bisher auch kein empirisches Datenmaterial hinsichtlich des Forschungsziels auffinden. Folglich sind für die Ermittlung erster Erkenntnisse hinsichtlich des übergeordneten Forschungsziels zunächst die von Netzwerken konkret durchgeführten Aktionen im Rahmen der Integration von Interesse. Daraus ergibt sich das erste Teilziel dieser Untersuchung, das in der Schaffung eines Verständnisses über das Integrationsvorgehen in der Praxis liegt, um daraus Anforderungen an eine Integrationsmethode abzuleiten. Neben dem Integrationsvorgehen der Netzwerkpraxis sind für die übergeordnete Zielsetzung ebenfalls bestehende Integrationsmethoden von Interesse. Auch wenn sie nicht speziell für den Einsatz in Unternehmensnetzwerken entwickelt wurden, können sie die angestrebte Methodenentwicklung unterstützen. Dies ist etwa im Rahmen der Bereitstellung von Techniken der Fall, die sich ebenfalls für den Einsatz in Netzwerken eignen oder sich unkompliziert für diesen anpassen lassen. Demzufolge liegt ein weiteres Teilziel der Arbeit in der Schaffung eines Verständnisses über die bestehenden Integrationsmethoden aus der Theorie um zu überprüfen, inwiefern sie sich für den Einsatz in Unternehmensnetzwerken eignen. In Anlehnung an die oben skizzierte Differenzierung zwischen Erkenntnis- und Gestaltungszielen lassen sich die ersten beiden Teilziele den Erkenntniszielen zuordnen. Zur umfassenden Bearbeitung des übergeordneten Forschungsziels bedarf es schließlich der Entwicklung einer ersten netzwerkspezifischen Integrationsmethode. Bereits in der Problemstellung wurde dafür auf die vorrangige Bedeutung der dafür nötigen Integrationsplanung und -bewertung hingewiesen, da sich für die im Anschluss erfolgende Realisierung einer Integrationslösung auf die bestehenden Ansätze des Netzwerkmanagements in Kombination mit den Ansätzen des klassischen Software Engineerings zurückgreifen lässt.30 Entsprechend liegt das letzte Teilziel der Untersuchung in der Entwicklung einer Methode zur Integrationsplanung und -bewertung und lässt sich gemäß der vorgestellten Systematisierung der For29 30

Vgl. Becker et al. (2004), S. 335-366. Vgl. im Detail Kapitel 4.1.

Zielsetzung und Methodik

7

schungsziele der Wirtschaftinformatik den Gestaltungszielen zuordnen (vgl. Abb. 1.3/1).

Übergeordnete Zielsetzung der Arbeit Aufarbeitung des Themenkomplexes „Integrationsmethoden für Unternehmensnetzwerke“

Verständnis über das Integrationsvorgehen in Netzwerken

Teilziele der Untersuchung

Überprüfung der Eignung bestehender Methoden für den Einsatz in Netzwerken

Erkenntnisziel

Entwicklung einer Methode zur Integrationsplanung und -bewertung in Netzwerken

Gestaltungsziel Forschungsziele der Wirtschaftsinformatik

Abb. 1.3/1: Systematisierung der Forschungsziele der Untersuchung

Ausgehend von der Zielsetzung der vorliegenden Untersuchung wird im Folgenden geklärt, welche wissenschaftliche Methodik zur Zielerreichung geeignet erscheint. Generell zielen wissenschaftliche Methoden auf die Sicherung eines systematischen Forschungsvorgehens zur Gewährleistung der intersubjektiven Nachvollziehbarkeit sowie -überprüfbarkeit wissenschaftlicher Aussagen.31 Die Auswahl einer Methode erfolgt dabei in Abhängigkeit von den angestrebten Aussagen hinsichtlich der jeweils untersuchten Forschungsziele.32 In Form der Beschreibungs-, Entdeckungs-, Begründungs- und Gestaltungszusammenhänge lassen sich hierbei allgemein vier Aussagenzusammenhänge unterscheiden. Erleichtert wird die Auswahl einer Methode durch ihre Systematisierung in zwei übergeordnete Richtungen. Dabei wird allgemein zwischen der induktiven und deduktiven Richtung unterschieden.33 Die Induktion als erste methodische Richtung ist ein Vorgehen, bei dem vom Besonderen auf das Allgemeine geschlossen wird.34 Dazu werden aus einer endlichen Anzahl von Einzelbeobachtungen allgemeingültige Aussagen mit universellem Geltungsanspruch abgeleitet. Durch diese im Rahmen der Induktion erzeugten allgemeingültigen Aussagen über einen untersuchten Sachverhalt eignet sich die Indukti31 32 33 34

Vgl. Chmielewicz (1994), S. 36-37. Vgl. Morgan (1980), S. 606. Vgl. etwa Chalmers (2001), S. 35-49 oder Schanz (1988), S. 40-44. Vgl. hierzu und im Folgenden Eberhard (1999), S. 32-35.

8

Einführung

on insbesondere für den Entdeckungszusammenhang.35 Für Begründungs- und Gestaltungszusammenhänge hingegen ist die Induktion nicht geeignet.36 Im Rahmen der Deduktion als zweite methodische Richtung wird – ausgehend von allgemeingültigen Aussagen aus Axiomen oder bestehenden Theorien – unter Zuhilfenahme von Ableitungsregeln auf spezielle Aussagen geschlossen.37 Der Erkenntnisgewinn erfolgt dabei, indem aus bestehenden Aussagen mittels logischer Folgerung neue Aussagen abgeleitet werden. Hinsichtlich wissenschaftlicher Aussagezusammenhänge eignet sich die Deduktion insbesondere für Entdeckungs-, Begründungs- und Gestaltungszusammenhänge.38 Die Gegenüberstellung der oben vorgestellten Forschungsziele mit den skizzierten grundsätzlichen Methodenrichtungen grenzt die für die vorliegende Untersuchung infrage kommenden Methoden ein. Wie beschrieben liegt das erste Forschungsziel in der Schaffung von Erkenntnissen über das Integrationsvorgehen in Netzwerken, um daraus Anforderungen an Integrationsmethoden abzuleiten. Für diese Fragestellung lassen sich bisher kaum geeignete Forschungsergebnisse auffinden. Somit wird zunächst eine explorative Untersuchung des Integrationsvorgehens in der Praxis angestrebt, die dem Entdeckungszusammenhang als Anwendungsbereich einer Methode entspricht. Damit bietet sich für das erste Forschungsziel ein induktives Vorgehen an, welches insbesondere für die Erkenntnisgewinnung im Entdeckungszusammenhang anzuwenden ist. Innerhalb der induktiven Ansätze lässt sich die Methodenwahl jedoch noch weiter eingrenzen. Wie die Literatur zur Auswahl geeigneter Methoden empfiehlt, sind für eine erste Annäherung an ein Forschungsproblem zunächst die Fragen nach dem „Wie“ und „Warum“ von vorrangiger Bedeutung.39 Zur Klärung dieser Fragen eignen sich als Forschungsmethode insbesondere Fallstudien, bei denen zu untersuchende Phänomene durch einzelne, jedoch vertiefende Beobachtungen einer ganzheitlichen Analyse unterzogen werden.40 Zur Erreichung des ersten Forschungsziels der vorliegenden Untersuchung sollen demzufolge vier Fallstudien zur explorativen Untersuchung des Integrationsvorgehens in Unternehmensnetzwerken beitragen. Das zweite Forschungsziel der vorliegenden Arbeit verfolgt wie skizziert die Überprüfung der Eignung bestehender Integrationsmethoden für ihren Einsatz in Unterneh-

35 36 37 38 39 40

Zum Entdeckungszusammenhang vgl. Chmielewicz (1994), S. 36. Vgl. Schweitzer (2000), S. 74. Vgl. Schanz (1988), S. 44-46. Vgl. Schweitzer (2000), S. 74. Vgl. zur explorativen Absicht von Fallstudien etwa Schnell et al. (2005), S. 251. Vgl. Bonoma (1985), S. 207; Yin (2003), S. 5-11. Für eine ausführliche Diskussion der hier verwendeten Fallstudien vgl. auch Kapitel 2.2.1.

Aufbau und Entstehungskontext der Arbeit

9

mensnetzwerken. Dafür ist durch logisches Ableiten zu untersuchen, inwiefern die bestehenden Methoden das aufgedeckte Integrationsvorgehen und die daraus resultierenden Anforderungen einer Integrationsmethode für Netzwerke berücksichtigen. Um dieses Forschungsziel zu erreichen, wird demzufolge ein deduktives Vorgehen für geeignet erachtet. Den Hintergrund dieser Einschätzung bildet die Stärke der Deduktion hinsichtlich der Aufdeckung von Begründungszusammenhängen zur Erreichung eines Erkenntnisziels.41 Das dafür benötigte domänenabhängige Vorwissen ist in Form der bestehenden Integrationsmethoden sowie in Form der (im Rahmen des ersten Forschungsziels) ermittelten Erkenntnisse über das Integrationsvorgehen in Netzwerken gegeben. Schließlich liegt das letzte Forschungsziel der vorliegenden Arbeit im Entwurf einer eigenständigen Integrationsmethode für Unternehmensnetwerke. Entsprechend der damit verbundenen Gestaltungsempfehlung eignet sich hierfür insbesondere die Deduktion als methodische Grundausrichtung. Auch hier liegt in Form der Erkenntnisse aus den Fallstudien, den theoretischen Vorarbeiten zu Netzwerken sowie zur Integration und zu dessen Vorgehen, bereits ausreichendes domänenabhängiges Vorwissen für die Deduktion zugrunde. Durch logisches Ableiten lässt sich dieses entsprechend zu einer Integrationsmethode für Unternehmensnetzwerke zusammenführen. Aus der Beschreibung der Forschungsziele und der Zielsetzung wurde die hervorzuhebende Bedeutung von Vorgehensweisen innerhalb der vorliegenden Untersuchung ersichtlich. Um diese adäquat zu erfassen sowie zu dokumentieren, bietet sich das Method Engineering als Analyseinstrument an. Das Method Engineering wurde ursprünglich im Rahmen des Software Engineerings entwickelt, um die Vergleichbarkeit unterschiedlicher Methoden zur Softwareentwicklung zu ermöglichen.42 Im Kern werden dazu Methoden in fünf zentrale Komponenten gegliedert, womit sich Unterschiede sowie Gemeinsamkeiten aufdecken lassen und der Methodenentwurf vereinfacht ist.43 Wie eine Vielzahl von Arbeiten zeigt, eignet sich dieser Ansatz gleichermaßen zur Untersuchung und Entwicklung von Methoden außerhalb des Software Engineerings.44 Entsprechend sind sämtliche Vorgehensweisen und Methoden im Rahmen der vorliegenden Arbeit anhand des Method Engineerings strukturiert. 1.4

Aufbau und Entstehungskontext der Arbeit

Die vorliegende Arbeit gliedert sich in sechs Kapitel (vgl. Abb. 1.4/1). Im folgendem zweiten Kapitel stehen zunächst die Grundlagen der zwischenbetrieblichen Integra41 42 43 44

Vgl. Chmielewicz (1994), S. 90-95. Vgl. Heym (1993), S. 13-14. Vgl. im Detail Kapitel 2.1.3. Vgl. Hess (1996), S. 20.

10

Einführung

tion im Vordergrund. Am Anfang erfolgt deshalb die Einführung in die zentralen Begrifflichkeiten der Untersuchung. In diesem Rahmen wird auf Unternehmensnetzwerke, die Integration in Netzwerken sowie das Method Engineering als Analyseraster eingegangen. Auf diesen zentralen Begriffen aufbauend erfolgt die Vorstellung von vier Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken, woraus schließlich Anforderungen an eine Integrationsmethode für Unternehmensnetzwerke abgeleitet werden. Im dritten Kapitel werden bestehende Integrationsmethoden der Literatur hinsichtlich ihrer Eignung für den Einsatz in Unternehmensnetzwerken untersucht. Für einen ersten Überblick erfolgt zunächst eine Systematisierung der Methoden anhand ihrer methodischen Vollständigkeit sowie anhand des überwiegenden Methodefokus. Aus dieser Systematisierung ergeben sich schließlich vier Methoden, die anschließend im Detail untersucht und zum Abschluss des dritten Kapitels den ermittelten Anforderungen an eine Integrationsmethode für Unternehmensnetzwerke gegenübergestellt werden. 2

Grundlagen und Anforderungen

Netzwerke, Integration, Method Engineering

Fallstudien zur Integration in Netzwerken

Anforderungen an eine Integrationsmethode für Netzwerke

3

Methodenanalyse

Analyse der bestehenden Integrationsmethoden aus der Literatur

Beurteilung der Methoden für die Integrationsplanung und -bewertung in Netzwerken

4

Eckpunkte der Methode Methodenvorschlag

Metamodell

Aktivitäten -modell

Techniken

Ergebnismodell

Rollenmodell

5

Methodenevaluation

Anwendung der Methode an einem Praxisbeispiel

Abb. 1.4/1: Aufbau der Arbeit

Das vierte Kapitel greift die ermittelten Anforderungen einer Integrationsmethode sowie die Ergebnisse aus der Untersuchung der bestehenden Methode für den Entwurf einer netzwerkspezifischen Integrationsmethode auf. Nach der Vorstellung der Eckpunkte, an denen sich der Methodenentwurf orientiert, erfolgt die Darstellung der Methodenkomponenten gemäß der Strukturierung des Method Engineerings.

Aufbau und Entstehungskontext der Arbeit

11

Das fünfte Kapitel stellt die Überprüfung der entwickelten Methode an einem Fallbeispiel aus der Praxis vor. Dazu werden zunächst die Ergebnisse ihres Einsatzes in der Praxis beschrieben und im nächsten Schritt die Methode kritisch gewürdigt. Im abschließenden sechsten Kapitel werden die erhaltenen Ergebnisse der vorliegenden Untersuchung in einer Schlussbetrachtung zusammengefasst. Dabei erfolgt eine übergreifende kritische Würdigung sämtlicher Ergebnisse sowie die Vorstellung weiterer Ansatzpunkte für zukünftige Forschungsarbeiten zur Integration in Netzwerken. Entstanden ist die vorliegende Arbeit in der Forschungsgruppe „NetWorx“ des Instituts für Wirtschaftsinformatik und Neue Medien der Ludwig-Maximilians-Universität München. Grundsätzlich setzt sich die Forschungsgruppe mit betriebswirtschaftlichen und informationstechnischen Fragestellungen des Netzwerkmanagements auseinander. Lag der Fokus der Forschungsgruppe zu Beginn der Forschungsarbeit insbesondere auf generellen Fragen zum Netzwerkmanagement bzw. -controlling,45 so wird seit einiger Zeit speziell das Management des IT-Einsatzes in Netzwerken untersucht. Analysiert werden dabei sämtliche Phasen des IT-Einsatzes in Netzwerken, ausgehend von der der Identifikation vorteilhafter Einsatzmöglichkeiten über die Bewertung kollektiver IT-Investitionen bis hin zur Gestaltung interorganisationaler Anwendungssysteme. In diese Arbeit unmittelbar eingeflossen sind entsprechend die Erkenntnisse aus den Arbeiten zur Gestaltung von IT-Werkzeugen zur Unterstützung interner Märkte in Netzwerken sowie zur Bewertung unternehmensübergreifender ITInvestitionen.46

45 46

Vgl. Hess (2002a). Vgl. Wittenberg (2004) sowie Hirnle (2006).

2 Grundlagen und Methodenanforderungen Dieser Abschnitt stellt die zentralen Grundlagen der vorliegenden Untersuchung vor und leitet die Anforderungen einer Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken ab. Dafür steht in Kapitel 2.1 zunächst die Vorstellung und Einordnung der grundlegenden Begriffe im Mittelpunkt. Diese umfassen die Unternehmensnetzwerke, die zwischenbetriebliche Anwendungssystemintegration sowie das Method Engineering als Analyseansatz. Darauf aufbauend stellt Kapitel 2.2 vier mittels des Method Engineering strukturierte Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken vor. Abschließend leitet Kapitel 2.3 anhand der Erkenntnisse der Fallstudien und der vorgestellten grundlegenden Begriffe Anforderungen an eine Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken ab. 2.1

Grundlegende Begriffe

2.1.1 Unternehmensnetzwerke Die wissenschaftliche Betrachtung von Unternehmensnetzwerken ist ein noch junges Forschungsfeld. Erst seit den letzten ein bis zwei Dekaden kommt ihr verstärkte Aufmerksamkeit zu. Zahllose Definitionsansätze brachten die Forschungsbemühungen seither hervor.47 Eine einheitliche Begriffssystematik lässt sich daraus jedoch nicht entnehmen. Somit bedarf es vor einer vertiefenden Analyse einer Konkretisierung des zugrunde liegenden Netzwerkverständnisses. Ausgehend von der Transaktionskostentheorie wird dafür in Kapitel 2.1.1.1 die Eingliederung von Netzwerken als hybride Organisationsform zwischen Markt und Hierarchie vorgenommen. Davon ausgehend erfolgt in Kapitel 2.1.1.2 die Vorstellung von Netzwerken als eine spezielle zwischenbetriebliche Kooperationsform mit unterschiedlichen Ausgestaltungsvarianten. Abgeschlossen wird die Darstellung des Netzwerkverständnisses in Kapitel 2.1.1.3 durch die Systematisierung unterschiedlicher Netzwerkformen und deren Auswirkung auf das Netzwerkmanagement. 2.1.1.1

Kooperationen zwischen Markt und Hierarchie als Ausgangspunkt

Zur Erklärung der Entstehung und Organisation von Unternehmensnetzwerken hat sich bisher noch keine, auf breiter Basis anerkannte Theorie durchgesetzt.48 Vielmehr werden dafür unterschiedliche, meist ökonomisch geprägte Theorien herangezogen.

47 48

Vgl. Borgatti/Foster (2003), S. 992. Vgl. etwa Franz (2003), S. 27. Siehe auch Sydow (1999), S. 165 sowie im Detail Sydow (1992), S. 127.

14

Grundlagen und Methodenanforderungen

Häufige Verwendung finden dabei ressourcenorientierte, spieltheoretische oder koordinationstheoretische Ansätze.49 Innerhalb der Literatur kommt jedoch dem Transaktionskostenansatz zur Erklärung der Entstehung und Organisation von Unternehmensnetzwerken die höchste Aufmerksamkeit zu.50 Zur Erklärung dieser herausragenden Bedeutung des Ansatzes zur theoretischen Fundierung von Unternehmensnetzwerken wird typischerweise dessen Fokus auf Faktoren aufgeführt, die Individuen bei der Wahl einer effizienten Organisationsform für ihr wirtschaftliches Handeln beeinflussen.51 Begründet wurde der Transaktionskostenansatz durch Williamson in den 1970er Jahren, der rechtliche und organisationstheoretische Konzepte mit grundlegenden Vorarbeiten von Coase aus den 1930er Jahren zur Frage der Bildung von Unternehmen verknüpft.52 Zentraler Bestandteil des Ansatzes ist die Ermittlung von Kosten (Transaktionskosten), die bei der Übertragung (Tranksaktion) von Verfügungsrechten (Property-Rights) zwischen wirtschaftlich handelnden Akteuren entstehen. Sie lassen sich auf Aufwendungen zur (1) Anbahnung (etwa Recherchen, Reisen, Beratung), (2) Vereinbarung (etwa Verhandlungen, Klärung rechtlicher Fragen), (3) Abwicklung (etwa Prozesssteuerung der Transaktion), (4) Kontrolle (etwa Qualitäts- und Terminüberwachungen) sowie (5) Anpassung (etwa Zusatzkosten aufgrund nachträglicher Qualitäts-, Preis- oder Terminabweichungen) im Rahmen der Verfügungsrechteübertragung zurückführen.53 Ihre Höhe bemisst sich zum einen nach der gewählten Organisationsform54 sowie zum anderen nach den jeweiligen Eigenschaften der Transaktion.55 Diese werden durch ihre Spezifität56 sowie durch die Häufigkeit ihrer Durchführung und bestehender Unsicherheit aufgrund von beschränkter Rationalität und opportunistischem Verhalten der Akteure bestimmt.57 Das Ziel des Transaktionskostenansatzes liegt in der Auswahl der Organisationsform mit minimalen Transaktionskosten bei gegebenen Eigenschaften einer Transaktion. Stark vereinfacht besteht dabei die Annahme, dass bei zunehmender Spezifität die

49 50 51 52 53 54

55 56

57

Vgl. zur Diskussion etwa Wang et al. (2004), S.75-90; Fleisch (2001), S. 61-103. Vgl. etwa Franz (2003), S. 27; Sydow (1992), S. 127. Vgl. Ebers/Gotsch (2001), S. 225. Vgl. Wolff/Neuburger (1995), S. 77. Vgl. Picot et al. (2003), S. 49. Ursprünglich unterscheidet Willamson dabei zwischen marktlicher oder hierarchischer Organisation (vgl. Williamson (1975)). Vgl. Picot et al. (2003), S. 49. Darunter werden die von den Transaktionspartnern getätigten spezifischen Investitionen zur Erstellung des zu tauschenden Gutes gefasst (vgl. Bea/Göbel (1999), S. 134-135). Vgl. Ebers/Gotsch (2001), S. 280. In der Literatur zum Transaktionskostenansatz finden sich je nach Autor noch weitere transaktionspezifische Eigenschaften. Auf eine umfassende Darstellung möglicher Eigenschaften wird jedoch aufgrund der sich dadurch nicht verändernden Kernaussage des Transaktionskostenansatzes im Rahmen der vorliegenden Arbeit verzichtet.

Grundlegende Begriffe

15

Abwicklung einer Transaktion in der Organisationsform Unternehmen effizienter ausgestaltet ist.58 Die ursprüngliche Konzeption des Transaktionskostenansatzes unterscheidet lediglich die marktliche oder hierarchische Organisationsform. Zwischen diesen ursprünglichen Formen wird etwa seit den 1980er Jahren in Form von Unternehmenskooperationen eine dritte, hybride Organisationsform eingeordnet, innerhalb der sowohl marktliche als auch hierarchische Charakteristika vereint sind. Hybride Organisationsformen werden dann als effizient bezeichnet, wenn aufgrund von abnehmender Spezifität einer Transaktion ein hierarchisch stabiler Rahmen nicht mehr erforderlich ist. Gleichzeitig sind die Transaktionseigenschaften jedoch derart angelegt, dass ihre anonyme Durchführung am Markt – etwa aufgrund opportunistischen Verhaltens oder durch den nötigen Abstimmungsbedarf der beteiligten Akteure – nicht effizient auszugestalten ist.59 Abb. 2.1.1.1/1 verdeutlicht den Zusammenhang zwischen der unterschiedlichen Ausgestaltung von Transaktionskosten bei gegebenem Spezifitätsgrad für die drei Organisationsformen graphisch. Transa ktionskosten (TAK)

marktliche Orga nisation

hybride Orga nisation

hiera rchische Orga nisation

TAK (s, Markt)

TAK (s, Hierarchie) TAK (s, hybrid)

s

Spezifitätsgrad (s)

Abb. 2.1.1.1/1: Transaktionskosten bei gegebener Spezifität60

Nicht übersehen werden soll allerdings, dass die in diesem Abschnitt vorgestellte Einordnung von Kooperationen als hybride Form zwischen Markt und Hierarchie eine mögliche Sichtweise darstellt. Ebenfalls Verbreitung findet ein Ansatz, bei dem Unternehmenskooperationen nicht als hybride Form aufgefasst werden, sondern eine

58

59 60

Vgl. Wolff/Neuburger (1995), S. 78. Gemäß dieser Annahme eignen sich bei steigender Spezifität einer Transaktion Unternehmen besser, da dort im Vergleich zum Markt Überwachungs- und Anpassungsmechanismen fortlaufend-administrativer Art effizienter eingeführt werden können sowie der hierarchisch stabile Rahmen ein opportunistisches Ausnutzen von Abhängigkeiten verhindert (vgl. Göbel (2002), S. 143-145). Vgl. Wolff/Neuburger (1995), S. 84. In Anlehnung an Picot et al. (2005), S. 70; Michaelis (1985), S. 103.

16

Grundlagen und Methodenanforderungen

eigenständige Kooperationsform darstellen.61 Die Vertreter dieser Auffassung betonen als konstituierendes Merkmal dieser dritten Organisationsform insbesondere die Rolle des Vertrauens, welches die Möglichkeiten eines opportunistischen Verhaltens der Kooperationsteilnehmer vermindert.62 Kritik wird diesem Ansatz im Hinblick auf das enthaltene Verständnis der Organisationsformen entgegengebracht.63 So handelt es sich bei Markt und Hierarchie um idealisierte Organisationsformen, die typischerweise nicht in dieser Reinform vorkommen. Vielmehr beinhalten Märkte hierarchische Elemente. Umgekehrt enthalten Hierarchien marktliche Elemente. Die Gegenpole Markt und Hierarchie werden entsprechend durch eine Reihe von zwischen ihnen liegenden Kooperationsformen ergänzt, zu denen unter anderen auch Unternehmensnetzwerke gehören. Dieser Auffassung wird in der vorliegenden Arbeit gefolgt. Die Einordnung von Unternehmensnetzwerken als hybride Organisationsform zwischen Markt und Hierarchie ist allerdings als Definition im Rahmen der vorliegenden Arbeit zu allgemein gehalten. Entsprechend lassen sich unterschiedliche Ausprägungen von Kooperationen auf einem Kontinuum feststellen. In Folge dessen wird im Anschluss eine managementorientierte Systematisierung von möglichen Kooperationsformen zwischen Unternehmen vorgestellt, von der schließlich Unternehmensnetzwerke abgegrenzt werden. 2.1.1.2

Netzwerke als zwischenbetriebliche Kooperation

Mit dem Kooperationsbegriff setzt sich die betriebswirtschaftliche Forschung seit geraumer Zeit auseinander und hat dabei nicht zuletzt eine Reihe von Definitionsversuchen hervorgebracht.64 Eine umfassend anerkannte Definition findet sich darunter allerdings nicht. Zur Abgrenzung des Kooperationsbegriffs im Rahmen von Arbeiten zum Management in Unternehmensnetzwerken hat sich jedoch der Rückgriff auf bestehende Gemeinsamkeiten zwischen den unterschiedlichen Definitionsansätzen als praktikabel erwiesen.65 Die dazu erfolgte Suche nach einem Minimalkonsens zwischen den bestehenden Kooperationsdefinitionen deckt zwei wiederkehrende Anhaltspunkte innerhalb der verbreiteten Definitionen auf. Typischerweise werden zum einen die Abhängigkeitsverhältnisse der beteiligten Unternehmen und zum anderen die Kooperationsziele im Rahmen der bestehenden Kooperationsdefinition aufgeführt.

61 62 63 64

65

Vgl. zur Diskussion Bienert (2002) 86-97; Klein (1996), S. 98-93; Krebs/Rock (1994), S. 323-337. Vgl. Loose/Sydow (1994) S. 161-163; Sydow (1992), S. 101-104; Powell (1990), S. 299. Vgl. Sydow (1992), S. 102. Vgl. beispielsweise Rupprecht-Däullary (1994) S. 5-18; Rotering (1990), S. 38-41; Tröndle (1987), 13-23 sowie die dort angegebenen Literaturhinweise. Vgl. zu diesem Vorgehen etwa Hirnle (2006), S. 14; Rupprecht-Däullary (1994), S. 16; Kraege (1997), S. 50-51.

Grundlegende Begriffe

17

Wird das Abhängigkeitsverhältnis untersucht, so lassen sich Kooperationen mit mindestens zwei rechtlich und (zumindest vor Kooperationsbeginn)66, wirtschaftlich selbständigen Partnerunternehmen von Kooperationen mit unselbständigen Partnerunternehmen unterscheiden. Die rechtliche und wirtschaftliche Selbständigkeit impliziert, dass die involvierten Partner einer Kooperation frei über ihren Ein- oder Austritt entscheiden können. Dabei sind sie keinerlei Weisungsbefugnissen einer übergeordneten, formal legitimierten Instanz unterworfen. Vielmehr erfolgt die Zusammenarbeit auf weitgehend freiwilliger Basis. Bei der Analyse des Kooperationsziels als zweiter wiederkehrender Aspekt innerhalb der bestehenden Kooperationsdefinitionen, lassen sich des Weiteren solche Kooperationen mit der Ausrichtung auf ein leistungswirtschaftliches Sachziel in Form der Erstellung eines marktlich verwertbaren Produkts oder einer Dienstleistung von Kooperationen ohne dieses Ziel unterscheiden.67 Anhand dieses Begriffpaares (Abhängigkeitsverhältnis sowie Kooperationsziel) mit den jeweils zwei unterschiedlichen Ausprägungen lassen sich drei Kooperationsgrundformen differenzieren, die im Folgenden skizziert werden (vgl. Abb. 2.1.1.2/1). Kooperationsform

innerbetriebliche Kooperation

überbetriebliche Kooperation

zwischenbetriebliche Kooperation

rechtlich und (vor Kooperationsbeginn) wirtschaftlich selbständige Partner

nicht erfüllt

erfüllt

erfüllt

Verfolgung eines leistungswirtschaftlichen Sachziels

erfüllt

nicht erfüllt

erfüllt

Merkmal

Abb. 2.1.1.2/1: Grundformen der betrieblichen Kooperation68

Innerbetriebliche Kooperationen als erster Grundtyp sind durch die fehlende rechtliche und wirtschaftliche Selbständigkeit der Partnerunternehmen bei gleichzeitiger Verfolgung eines leistungswirtschaftlichen Sachziels gekennzeichnet. Als Beispiel für innerbetriebliche Kooperationen lassen sich Konzerne aufführen, bei den zum einen leistungswirtschaftliche Sachziele verfolgt werden, die beteiligten Unternehmen je66

67

68

Die Betonung der wirtschaftlichen Selbständigkeit lediglich vor dem Kooperationsbeginn hat häufig entstehende Ressourceninterdependenzen und irreversible Investitionen (Sunk Costs) der teilnehmenden Partner im Laufe einer Kooperation als Hintergrund. Ein Austritt ohne wirtschaftlichen Nachteil ist für Kooperationsteilnehmer insofern regelmäßig nicht zu erwarten. Zur Diskussion des Zeitpunkts der wirtschaftlichen Selbständigkeit vgl. etwa Sydow (1992), 90-93; Jarillo/Ricart (1987), S. 81. Ihre Ziele könnten in der Stärkung einer Branche liegen, bei beispielsweise einer Unternehmenskooperation innerhalb eines Wirtschaftsverbands. In Anlehnung an Wohlgemuth (2002), S. 14; Hess (2002a), S. 9.

18

Grundlagen und Methodenanforderungen

doch in ihrer Selbständigkeit eingeschränkt sind, da sie etwa nicht frei über ihren Konzernein- und -austritt entscheiden können.69 Überbetriebliche Kooperationen kennzeichnen sich hingegen durch eine bestehende rechtliche Selbständigkeit der Partner, wobei diese kein leistungswirtschaftliches Sachziel verfolgen. Überbetriebliche Kooperationen bestehen etwa in Form von Unternehmensverbänden, bei denen die beteiligten Partner meist über das Ausmaß ihrer Involvierung sowie über ihren Ein- und Austritt selbständig entscheiden können. Das Ziel einer überbetrieblichen Kooperation liegt jedoch nicht in der Erstellung eines martklich verwertbaren Produkts bzw. einer Dienstleistung, sondern vielmehr in der Stärkung der beteiligten Unternehmen.70 Zwischenbetriebliche Kooperationen zu denen Unternehmensnetzwerke zählen, kennzeichnen sich schließlich sowohl durch eine bestehende rechtliche und wirtschaftliche Selbständigkeit von mindestens zwei Partnerunternehmen als auch durch die Verfolgung eines gemeinsamen wirtschaftlichen Sachziels. Zusätzlich zu Unternehmensnetzwerken trifft diese Kennzeichnung allerdings auch auf Joint Ventures und Strategische Allianzen zu.71 Für eine genauere Abgrenzung des Netzwerksbegriffs bedarf es insofern einer differenzierten Betrachtung zwischenbetrieblicher Kooperationen. Hierzu hat sich die Analyse der drei Charakteristika (a) „Art der Funktionsverknüpfung“, (b) „Befristung der Zusammenarbeit“ sowie (c) „Anzahl beteiligter Partnerunternehmen“ als praktikabel erwiesen.72

(a) Mit der Funktionszusammenlegung oder Funktionsabstimmung lassen sich zunächst zwei Arten der Funktionsverknüpfung unterscheiden.73 Die Funktionszusammenlegung ist durch die Poolung von kooperationsspezifischen Ressourcen gekennzeichnet. Die dadurch anfallenden Kosten und Erlöse werden auf die Partner verteilt. Im Vergleich dazu fallen bei der Funktionsabstimmung die sich ergebenden Kosten und Erlöse bei den beteiligten Partnern an.74

69

70 71 72 73 74

Vgl. Kraege (1997), S. 52. Damit beim Konzernbeispiel von einer Kooperation gesprochen werden kann dürfen allerdings zwischen den beteiligten Unternehmen keine Weisungsbeziehungen bestehen (vgl. etwa Sydow (2001), S. 271-298). Vgl. Hess (2002a), S. 8-9. Vgl. Wohlgemuth (2002), S. 15-17; Hess (1999), S. 225. Vgl. beispielsweise Hirnle (2006), S. 14-16; Wittenberg (2004), S. 14. Vgl. Kraege (1997), S. 67; Rupprecht-Däullary (1994), S. 21-22. Auf Funktionszusammenlegung beruhende Kooperationen werden gemäß Tröndle auch als „redistributiv“ bezeichnet, wobei hingegen auf Funktionsabstimmung basierende Kooperationen als „reziprok“ bezeichnet werden (vgl. Tröndle (1987), S. 19-22).

Grundlegende Begriffe

19

(b) Bei der Befristung von Kooperation lassen sich befristete Kooperationen von unbefristeten unterschieden. Befristete Kooperationen sind sachlich (einzelne oder mehrere vorab bestimmte Vorhaben) oder zeitlich (vorab definierte Kooperationsdauer) begrenzt.75 (c) Schließlich wird die Anzahl der beteiligten Partnerunternehmen als drittes Merkmal zur Klassifizierung zwischenbetrieblicher Kooperationen herangezogen. Kooperationen mit genau zwei Partnern werden dabei als „bilateral“ bezeichnet. Multilaterale Kooperationen sind hingegen durch mindestens drei und mehr Partner gekennzeichnet.76

Abb. 2.1.1.2/2 zeigt die skizzierten Charakteristika zwischenbetrieblicher Kooperationsformen im Überblick. Grundtyp Joint Venture

Strategische Allianz

Unternehmensnetzwerk

Funktionszusammenlegung mit rechtlicher Struktur

Funktionsabstimmung auf Vertragsbasis

Funktionsabstimmung auf Vertragsbasis

unbefristet

befristet

unbefristet

mindestens zwei, typischerweise weniger als fünf

mindestens zwei, typischerweise weniger als fünf

mindestens drei, oft zehn und mehr

Merkmal Art der Funktionsverknüpfung

Befristung

Anzahl der Partner

Abb. 2.1.1.2/2: Charakteristika der Grundtypen zwischenbetrieblicher Kooperation77

Ein Joint Venture ist eine von zwei oder mehr Kooperationspartnern gegründete, rechtlich selbständige Gemeinschaftsunternehmung. Die Partnerunternehmen stellen zur Unternehmensgründung und -führung Ressourcen bereit und sind entsprechend meist zu etwa gleichen Teilen am Joint Venture beteiligt. Joint Ventures sind meist sachlich oder zeitlich unbefristet. Besondere Bedeutung kommt ihnen etwa im Rahmen von Internationalisierungsstrategien zu.78 Im Rahmen von strategischen Allianzen schließen sich mindestens zwei, jedoch meist weniger als fünf Kooperationspartner zu zeitlich oder sachlich beschränkten Vorhaben zusammen. Häufig lassen sich strategische Allianzen im Rahmen von For-

75 76 77 78

Vgl. Wohlgemuth (2002), S. 15. Vgl. Lutz (1993), S. 55. Vgl. Hess (2002a), S. 11. Vgl. Sydow (1992), S. 62-65.

20

Grundlagen und Methodenanforderungen

schungs- und Entwicklungsprojekten, etwa zwischen Unternehmen und Forschungsinstituten oder zwischen im Wettbewerb zueinander stehenden Unternehmen finden, die nach Beendigung der strategischen Allianz wieder als konkurrierende Marktrivalen auftreten.79 Den dritten Grundtypus zwischenbetrieblicher Kooperationen stellen schließlich Unternehmensnetzwerke dar. Im Vergleich zu den zuvor beschriebenen Typen ist ihre Charakterisierung derzeit jedoch noch nicht auf ein vergleichbares Niveau konsolidiert. Einigkeit findet sich weitestgehend bei der Anzahl von Partnerunternehmen eines Netzwerkes, die deutlich die Anzahl der Partner von Joint Ventures und strategischen Allianzen übersteigen.80 Ebenfalls herrscht weitgehend Einigkeit über eine bestehende Funktionsabstimmung der beteiligten Partnerunternehmen sowie über die meist fehlende sachliche und zeitliche Befristung von Netzwerken. Aufgrund des fehlenden gesellschaftlichen Rahmens für die Zusammenlegung von Ressourcen, die sich dadurch ergibt, dass die rechtliche Basis der Zusammenarbeit meist formlos oder vertraglich festgehalten ist, wird die Funktionsabstimmung in Netzwerken meist projektbezogen koordiniert.81 Die rechtliche Selbständigkeit der Partner führt bei Unternehmensnetzwerken dazu, dass hierarchische Koordinationsinstrumente wie „Pläne“ und „Anweisungen“ im Vergleich zu marktlichen Koordinationsinstrumenten wie „Wettbewerb zwischen den Partnern“ zurücktreten.82 2.1.1.3

Formen und Ausgestaltung von Netzwerken

Der Einsatz der oben skizzierten marktlichen oder hierarchischen Instrumente zur Koordination eines Netzwerks ist nicht zuletzt von der jeweiligen Grundform des Netzwerks abhängig. Anhand der Merkmale von Steuerungsform und Stabilität eines Netzwerks lassen sich vier Formen unterscheiden.83 Mittels der Steuerungsform wird die bestehende Entscheidungsgewalt innerhalb des Netzwerks thematisiert. Differenziert werden zum einen fokale Netzwerke, bei denen ein einzelnes oder eine Gruppe von Partnerunternehmen Entscheidungsgewalt über die restlichen Partner haben. Zum anderen haben sie polyzentrische Netzwerke, bei denen die Entscheidungen des Netzwerks zwischen den Partnern mehrheitlich gleichberechtigt getroffen werden. Die Stabilität als zweites Merkmal zur Systematisierung von Unternehmensnetzwerken beschreibt die unterschiedliche Beteiligung der Partner bei der Auftrags-

79 80 81 82 83

Vgl. Hamel et al. (1989), S. 133-136; Servatius (1987), S. 222. Vgl. etwa Klein (1996), S. 88. Vgl. Hess (2002a), S. 11; Wohlgemuth (2002), S. 17. Vgl. z. B. Siebert (2003), S. 10. Vgl. hierzu und zu den Merkmalen Stabilität und Steuerungsform Sydow (2003), S. 300-303; Wohlgemuth (2002), S. 20-21. Zu weiteren Charakterisierungsmerkmalen von Netzwerken vgl. etwa Klein (1996), S. 127-133; Corsten (2001), S. 7.

Grundlegende Begriffe

21

durchführung. In stabilen Netzwerken werden mehrere Aufträge mit identischen Partnerunternehmen durchgeführt. In instabilen Netzwerken hingegen ändert sich die Beteiligung der Partner an der Leistungserstellung im Extremfall bei jedem Auftrag.84

fokal

Aus der Gegenüberstellung der zwei Merkmale mit ihren Ausprägungsmöglichkeiten ergeben sich vier Varianten von Unternehmensnetzwerken (vgl. Abb. 2.1.1.3/1).

Strategisches Netzwerk

Projektnetzwerk

Verbundnetzwerk

Virtuelles Unternehmen

polyzentrisch

Steuerungsform

stabil

instabil

Stabilität der Konfiguration

Abb. 2.1.1.3/1: Idealtypische Grundvarianten von Unternehmensnetzwerken85

Projektnetzwerke stellen die klassische Variante von Unternehmensnetzwerken dar. Sie lassen sich häufig in der Baubranche oder bei Filmproduktionen beobachten.86 Gekennzeichnet sind sie durch einen fokalen Partner, etwa ein Generalunternehmen, der weitere beteiligte Partner projektspezifisch konfiguriert. Strategische Netzwerke und Verbundnetzwerke zeichnen sich im Vergleich dazu durch eine stabile Konfiguration aus. Erstere lassen sich häufig in Form von Zulieferernetzwerken der Automobilindustrie auffinden, bei denen meist der OEM eine fokale Rolle übernimmt.87 Eine solche fokale Rolle fehlt hingegen in Verbundnetzwerken, die sich in Kooperationen von Luftverkehrsgesellschaften oder Verkehrsverbünden größerer Städte finden lassen.88 Virtuelle Unternehmen setzen sich in der Regel für neue Aufträge unterschiedlich zusammen. Damit sind sie durch eine instabile Konfiguration gekennzeichnet. Ebenfalls sind die individuellen Einflussmöglichkeiten der Partnerunternehmen gleich verteilt, so dass Unternehmensnetzwerke durch eine polyzentrische Steuerungsform

84

85 86 87 88

Vgl. etwa Snow et al. (1992), S. 13-14. Mit der Stabilität wird insofern nicht die Stabilität des Netzwerks im Sinne von dessen zeitlicher Befristung erfasst, sondern lediglich die Stabilität der Konfiguration von Partnerunternehmen bei der Auftragsbearbeitung. Vgl. Hess (2002a), S. 15. Vgl. Ebers et al. (2000), S. 253-260; Windeler et al. (2000), S. 180-185. Vgl. Semlinger (2003), S. 57-67; Köhler (2000), S. 280-286. Vgl. Wohlgemuth (2002), S. 23.

22

Grundlagen und Methodenanforderungen

charakterisiert sind.89 Nicht ausschließlich, jedoch häufig, lassen sie sich im Dienstleistungsbereich sowie in der IT- und Medienbranche beobachten.90 Der Rückgriff auf Steuerungsform und Stabilität zur Typologisierung macht auf eine Besonderheit von Unternehmensnetzwerken aufmerksam. So lässt sich bei Unternehmensnetzwerken zwischen einer Beziehungs- und einer Leistungsebene unterscheiden (vgl. 2.1.1.3/2).91 Die konstituierenden Merkmale eines Netzwerks in Form der Abgrenzung von beteiligten Partnern, der untereinander bestehenden Beziehungen sowie existierender formeller und informeller Regelungen umfassen den Betrachtungsgegenstand der Beziehungsebene. Aus dem abgegrenzten und ausgestalteten Unternehmensnetzwerk schließt sich schließlich eine bestimmte Anzahl von Partnerunternehmen zur Auftragsbearbeitung zusammen. Die dafür zu etablierenden und zu steuernden materiellen und immateriellen Leistungsbeziehungen stellen den Betrachtungsgegenstand der Leistungsebene dar. Auftrag 1

Auftrag 2

Auftrag n

Leistungsebene (konstituierende Merkmale der jeweiligen Auftragsbearbeitung)

Unternehmen 1

Beziehungsebene (konstituierende Merkmale des Netzwerks)

Unternehmen 2

Unternehmen 4

Unternehmen 3

Unternehmen...

Partnerpool

Abb. 2.1.1.3/2: Zwei-Ebenen-Architektur von Unternehmensnetzwerken92

Die Unterscheidung zwischen einer Beziehungs- und einer Leistungsebene richtet die Aufmerksamkeit auf eine weitere Besonderheit in Unternehmensnetzwerken. Der Zwei-Ebenen-Architektur folgend, kennzeichnen sich diese durch zwei weitgehend voneinander unabhängige Domänen des Managements von Unternehmensnetzwerken.93 Zum einen zielt das Management auf die Steuerung der Beziehungsebene so89 90

91 92 93

Vgl. Davidow/Malone (1993); Alt et al. (2005), S. 7-11; Schräder (1996). Vgl. z. B. Tschandl (2000), S. 76-77; Mertens et al. (1998) 17-52; Picot/Neuburger (2001), S. 803823. Vgl. Reiß (2000), S. 221-222. Ähnlich von Stengel (1999), S. 175-176. In Anlehnung an Hess (2002a), S. 13. Vgl. Reiß (2000), S. 227; Wohlgemuth (2002), S. 39-41; Hess (2002a), S. 20. Reiß lehnt sich bei der Differenzierung an die Unterscheidung aus der Managementlehre zwischen TaskManagement (für die Leistungsebene) und People-Management (für die Beziehungsebene) an. Hess und Wohlgemuth lehnen sich hingegen an die verbreitete Unterscheidung in operatives (für

Grundlegende Begriffe

23

wie zum anderen auf die der Leistungsebene. Das Management der Beziehungsebene betrifft alle Partner des Netzwerks und versucht die Netzwerkstrukturen effektiv auszugestalten. Es betrifft somit langfristige und grundsätzliche Aspekte des Netzwerks. Das Management auf der Leistungsebene bezieht sich hingegen auf die an einem Auftrag beteiligten Partner mit dem Ziel, die jeweilige Leistungserstellung effizient auszugestalten. Somit ist das Management kurzfristig lediglich auf die Dauer der Auftragsbearbeitung angelegt. Wird die Planung und Bewertung von Integrationsbereichen gemäß dieser Unterscheidung betrachtet, ist sie dem Management auf der Beziehungsebene zuzuordnen. Dabei steht jedoch weniger die mögliche Verbesserung der interpersonellen Beziehungen innerhalb des Netzwerks im Vordergrund als vielmehr die Optimierung der Netzwerkinfrastruktur.94 Bevor ein entsprechender Ansatz vorgestellt wird, gilt es jedoch zunächst die mögliche Ausgestaltung integrierter Anwendungssysteme in Unternehmensnetzwerken zu beleuchten. 2.1.2 Zwischenbetriebliche Anwendungssystemintegration Neben der Abgrenzung von Unternehmensnetzwerken bedarf es einer Abgrenzung des der Untersuchung zugrunde liegenden Verständnisses der zwischenbetrieblichen Integration von Anwendungssystemen. Dazu folgt einführend in Kapitel 2.1.2.1 die Abgrenzung von Anwendungssystemen. Im Anschluss wird in Kapitel 2.1.2.2 auf den Hintergrund und die Charakterisierung der Anwendungssystemintegration eingegangen. Darauf aufbauend stellt Kapitel 2.1.2.3 eine Systematisierung der Ausgestaltung der Anwendungssystemintegration in Unternehmensnetzwerken vor. 2.1.2.1

Anwendungssysteme als Ausgangspunkt

Den Ausgangspunkt der zwischen- sowie innerbetrieblichen Anwendungssystemintegration stellen die Anwendungssysteme selbst dar. Trotz der besonderen Bedeutung von Anwendungssystemen in der Wirtschaftsinformatik wird ihr Begriff mitunter

94

die Leistungsebene) und strategisches Management (für die Beziehungsebene). Wohlgemuth bezeichnet die Managementaufgaben der Leistungsebene als Auftrags- und die der Beziehungsebene als Plattformmanagement. Das Plattformmanagement ist wiederum unterteilt in das Management zum Aufbau der Netzwerkstruktur (Strukturmanagement) und zur Koordination der Partnerunternehmen (Beziehungsmanagement). Entsprechend zählt der in der vorliegenden Untersuchung entwickelte Ansatz zur Planung und Bewertung integrierter Anwendungssysteme zum Strukturmanagement (vgl. Wohlgemuth (2002), S. 41). Ähnlich strukturiert Hess die Managementaufgaben für Unternehmensnetzwerke in eine auftragsbezogene (vgl. Leistungsebene) und eine auftragsübergreifende Ebene (vgl. Beziehungsebene). Innerhalb der auftragsübergreifenden Ebene unterscheidet er zwischen Erfolgs-, Partner und Aktionsmanagement. Die Planung und Bewertung integrierter Anwendungssysteme würde entsprechend dieser Unterscheidung zum Aktionsmanagement zählen, das explizit den Aufbau einer IKT-Infrastruktur enthält (vgl. Hess (2002a), S. 20).

24

Grundlagen und Methodenanforderungen

unscharf verwendet und mit verwandten Begrifflichkeiten wie Informationssystem und Informationstechnologie vermischt.95 Infolgedessen erfolgt zunächst eine Abgrenzung und Definition von Anwendungssystemen. Ausgangspunkt ist die Skizzierung des Informationsbegriffs innerhalb der Wirtschaftsinformatik. Darauf aufbauend erfolgt die Vorstellung von Informationssysteme und sich von diesen als Teilmenge abgrenzen lassende Anwendungssysteme. Über den Begriff Information existiert in der Wissenschaft kein einheitliches Verständnis.96 Der Vielzahl an vorhandenen Definitionen soll im Rahmen dieser Arbeit allerdings keine weitere hinzugefügt werden. Es bietet sich zur Definition des Informationsbegriffs im Rahmen der Wirtschaftsinformatik vielmehr die Begriffsabgrenzung anhand der drei Ebenen der Semiotik an.97 Diese strukturiert eine Nachricht von einem Sender an einen Empfänger anhand dreier Ebenen. Deren Ausgangspunkt sind physikalisch wahrnehmbare Signale, Zeichen und Symbole, die sich auf der untersten Ebene der Semiotik (Syntax) nach bestehenden Konventionen, wie beispielsweise Grammatikregeln, zusammensetzen.98 Dabei wird jedoch nicht auf einen Bedeutungszusammenhang eingegangen. Dies erfolgt auf der zweiten Ebene (Semantik), bei der durch die Zuweisung eines Bedeutungszusammenhangs aus den physikalisch wahrnehmbaren und nach den Konventionen der Syntax zusammengesetzten Signalen eine Nachricht wird. Der Kontext des Senders und Empfängers ist dabei jedoch nicht einbezogen. Daher können Nachrichten von einem Empfänger zwar verstanden, jedoch mehrdeutig ausgelegt werden.99 Durch die Berücksichtigung der Zielsetzung bzw. der sich daraus ableitenden Aufgaben stellt eine Nachricht schließlich zweckorientiertes Wissen dar. Der Semiotik folgend wird eine Information als zweckorientiertes Wissen definiert,100 wobei sich die Zweckorientierung auf die Zielsetzung bzw. die daraus abgeleiteten Aufgaben der Nachricht bezieht.101 Mittels des so definierten Informationsbegriffs lassen sich im Folgenden betriebliche Informationssysteme abgrenzen. Diese können allgemein als soziotechnische („Mensch-Maschinen-“)Systeme, bestehend aus menschlichen und/oder maschinellen Komponenten, verstanden werden, die zur Verarbeitung von Informationen ge-

95 96

97 98 99

100 101

Vgl. Ferstl/Sinz (2001), S. 8-9. Fischer (1999), S. 9. Vgl. u. a. Reischer (2004), S. 85-86; Krcmar (2003), S. 14; Brockhaus (1992), S. 8-9. Gemäß einer Untersuchung konnten allein 160 unterschiedliche Definitionen des Informationsbegriffs aufgefunden werden (vgl. Steinbruch (1978), S. 48). Vgl. etwa Krcmar (2003), S. 14-17; Fank (1996), S. 28-29. Vgl. Krcmar (2003), S. 16-17; Brockhaus (1992), S. 8-12; Hildebrand (1995), S. 7. So kann ein Empfänger etwa die Nachricht „Das ist gut!“ zwar prinzipiell verstehen. Ohne den zugehörigen Kontext kann er daraus jedoch kaum die Zielsetzung, bzw. die aus der Nachricht abzuleitenden Aufgaben erfassen. Vgl. Wittmann (1959), S. 14; Wedekind (1988), S. 15. Vgl. Hoffmann et al. (1996), S. 3; Haselbauer (1986), S. 6-7.

Grundlegende Begriffe

25

nutzt werden.102 Die Informationsverarbeitung bezieht sich dabei auf die Erfassung, Übertragung, Transformation, Speicherung sowie die Bereitstellung von Informationen.103 Entsprechend dieser Definition müssen im Rahmen der Verwendung von Informationssystemen nicht zwanghaft Informationstechnologien (IT) in Form von Hardund Softwarekomponenten eingesetzt werden. Vielmehr können Informationssysteme – wie etwa die Buchführung oder Kostenrechnung – auch völlig unabhängig von IT verwendet werden, wie dies etwa bei der Buchführung auch bis vor 20 Jahren meist geschehen ist.104 Informationssysteme lassen sich von weiteren Systemen eines Unternehmens bzw. Unternehmensnetzwerks abgrenzen. Abstrakt beschrieben kommen neben Informationssystemen Basissysteme zum Einsatz.105 Im Vergleich zur informationsverarbeitenden Funktion der Informationssysteme lassen sich Basissysteme zur Leistungserstellung einsetzen. Dafür sind Ressourcen von Beschaffungsmärkten zu beziehen, von den Basissystemen zu Produkten zu verarbeiten und im Anschluss an Absatzmärkte abzugeben. Kommt dieser Unterscheidung folgend den Basissystemen die Leistungserstellung zu, so werden Informationssysteme zur Planung, Steuerung und Kontrolle der Basissysteme eingesetzt. Im Gegensatz zu Leistungen verwenden und produzieren sie Informationen, die sie an die Umwelt und die Basissysteme abgeben bzw. von dort empfangen. Anwendungssysteme sind die automatisierten Teile eines Informationssystems.106 Somit sind sie ebenfalls soziotechnische Mensch-Maschinen-Systeme zur Informationsverarbeitung. Ihre Besonderheit innerhalb der Informationssysteme liegt allerdings in der Verwendung von Informationstechnologien (IT) in Form von Hard- und Softwarekomponenten.107 Mittels dieser wird eine Automatisierung von informationsverarbeitenden Aufgaben unterstützt. Insofern unterscheiden sich Anwendungssysteme durch eine Automatisierung der Informationsverarbeitung mittels ITKomponenten von allgemeinen Informationssystemen (vgl. Abb. 2.1.2.1/1).

102 103 104 105 106 107

Vgl. Krcmar (2003), S. 23; WKWI (1994), S. 81-82. Vgl. Fank (1996), S. 65. Vgl. Fischer (1999), S. 9. Vgl. im Folgenden Ferstl/Sinz (2001), S. 28-29. Vgl. Mertens et al. (2005), S. 4; Fischer (1999), S. 9. Vgl. Kaib (2002), S. 11.

26

Grundlagen und Methodenanforderungen

Umwelt

Informationssysteme (Informationsverarbeitung) nicht automatisiert

automatisiert = Anwendungssysteme

Basissysteme (Leistungserstellung)

Organisation Informationsfluss Leistungsfluss

Abb. 2.1.2.1/1: Abgrenzung von Anwendungssystemen108

Die Einordnung von betrieblichen Anwendungssystemen erfolgt in der Wirtschaftsinformatik typischerweise durch die Analyse ihres Aufgabengebiets bzw. ihrer Zielsetzung. Abgegrenzt werden entsprechend operative Anwendungssysteme von Planungs- und Kontrollsystemen.109 Operative Systeme dienen der Unterstützung der Leistungserstellung im Rahmen der Geschäftsprozesse. Sie lassen sich wiederum in Administrations- und Dispositionssysteme strukturieren. Erstere werden durch die Unterstützung der Massendatenverarbeitung zur Rationalisierung und zum Nachvollzug der Abläufe eingesetzt. Letztere hingegen sollen menschliche Aufgabenträger im Rahmen der Prozessdurchführung durch die Automatisierung von Routineentscheidungen, etwa zur Ressourcenschonung, entlasten. Planungs- und Kontrollsysteme dienen des Weiteren der Unterstützung der Unternehmensführung.110 Planungssysteme werden dabei für die mittel- und langfristigen Planungsprozesse eingesetzt. Dafür stellen sie die nötigen Informationen zur Verfügung und bereiten die Planungsentscheidung zusätzlich durch die Konzeption von Alternativentscheidungen vor. Kontrollsysteme hingegen dienen der Überwachung der Planungen, wobei sie typischerweise zusätzlich Hinweise auf korrigierende Maßnahmen bereitstellen. Zur dezidierten Einordnung der Anwendungssysteme von Unternehmensnetzwerken lässt sich die vorgestellte Unterscheidung in operative Systeme sowie Planungs- und Kontrollsysteme erweitern. Hintergrund der Erweiterung ist die Feststellung, dass sich Anwendungssysteme in Unternehmensnetzwerken bei einzelnen Partnern oder netzwerkübergreifend einsetzen lassen. So finden sich in Netzwerken neben den Systemen der beteiligten Partner zusätzlich übergreifende operative Anwendungssysteme, etwa zur unternehmensübergreifenden Steuerung der Materialflüsse einer 108 109 110

In Anlehnung an Ferstl/Sinz (2001), S. 28-29; Grochla (1975), S. 12-13; Steffen (2002), S. 14-15. Vgl. Teubner (1999), S. 54-56; Mertens et al. (2005), S. 4. Vgl. Ferstl/Sinz (2001), S. 29.

Grundlegende Begriffe

27

Supply Chain,111 sowie übergreifende Planungs- und Kontrollsysteme, etwa zur netzwerkweiten Erfolgsmessung.112 Insofern wird die vorgestellte Einordnung um die Unterscheidung in Anwendungssysteme der Partnerebene und Anwendungssysteme der Netzwerkebene erweitert (vgl. Abb. 2.1.2.1/2). Unternehmensnetzwerk

Planungs- und Kontrollsysteme zielsichere Planung und Kontrolle für Partner 1

Netzwerkübergreifende Planungs- und Kontrollsysteme zielsichere Planung und Kontrolle des Netzwerks

Netzwerkübergreifende operative Systeme Rationalisierung, Effizienz, Ressourcenschonung Rationalisierung, Effizienz, Ressourcenschonung des Netzwerks für Partner 1 operative Systeme (Administrations- und Dispositionssysteme)

Anwendungssysteme auf Partnerebene (Netzwerkpartner 1)

Anwendungssysteme auf Netzwerkebene

Planungs- und Kontrollsysteme zielsichere Planung und Kontrolle für Partner 2

operative Systeme (Administrations- und Dispositionssysteme) Rationalisierung, Effizienz, Ressourcenschonung für Partner 2

Anwendungssysteme auf Partnerebene (Netzwerkpartner 2)

Abb. 2.1.2.1/2: Anwendungssysteme und ihre Ziele in Unternehmensnetzwerken

2.1.2.2

Grundlagen der Integration

Im vorangestellten Abschnitt ließen sich Anwendungssysteme als Systeme definiert, innerhalb derer die Informationsverarbeitung automatisiert abläuft. Um diese Automatisierung voranzutreiben, wurde in den letzten Dekaden innerhalb von Unternehmen eine Vielzahl spezialisierter Anwendungssysteme zur Unterstützung eines Großteils der betrieblichen Aufgaben eingesetzt.113 So setzt etwa ein Lieferant neben weiteren Systemen ein Anwendungssystem zur Planung seiner Liefertermine und ein Produzent ein System zur Planung und Steuerung seines Produktionsprozesses (PPS). bzw. für seine Materialbedarfsplanung (MPR). 114 Im Rahmen ihres Einsatzes wurde bereits in den 1960er Jahren auf die Beziehungen zwischen den Anwendungssystemen hingewiesen.115 Vereinfacht lässt sich der Hin-

111

112 113

114 115

Vgl. Corsten/Gössinger (2001), S. 152; Friedrich (2002), S. 5-22. Für ein ERP-System zur Steuerung von operativen Prozessen eines Netzwerks etwa Katzy (2005), S. 50-51. Vgl. etwa Holten/Schulze (2001), S. 586-587. Derzeit setzt ein durchschnittliches Unternehmen 50, die Hotelkette Marriott 700 und der Automobilhersteller General Motors rund 5.000 spezialisierte Anwendungssysteme ein (vgl. Siebel (2004), S. 10). Vgl. zu diesen und weiteren Anwendungssystemen Mertens (2004). Eine der ersten Arbeiten zur Integration entstand bereits im Jahre 1966 (vgl. im Überblick Heilmann (1989), S. 47).

28

Grundlagen und Methodenanforderungen

tergrund dieser Beziehungen anhand einer abstrakten Beschreibung der Leistungserstellung in Form von Prozessen verdeutlichen.116 Der vereinfachten Beschreibung folgend, unterstützen Anwendungssysteme einzelne Prozessschritte, die sich in ihrer Gesamtheit zu Prozessen zusammensetzen. Prozessschritte – egal ob inner- oder zwischenbetrieblich – sind jedoch typischerweise nicht voneinander unabhängig, da sie zur Durchführung neben der erstellten Teilleistung zusätzlich meist auch Informationen aus den vorangestellten Prozessschritten benötigen.117 Sind diese Informationen in den Anwendungssystemen der vorangestellten Prozessschritte abgelegt, so bedarf es einer Form ihrer Übertragung.118 Mit zunehmender Menge der Informationen stellt eine manuelle Übertragung einen erheblichen Zusatzaufwand und eine deutliche Zeitverzögerung dar.119 Diese Nachteile lassen sich mittels der Verknüpfung der betroffenen Systeme zugunsten eines verbesserten Informationsflusses vermindern.120 Die Schaffung eines durchgängigen Informationsflusses und damit die (Wieder-)herstellung einer Einheit bezeichnet die Wirtschaftsinformatik als Integration (vgl. Abb. 2.1.2.2/1) und führt diese als eine ihrer Leitideen auf.121 Aufgrund bestehender zwischenbetrieblicher Leistungsverknüpfungen kann diese Herstellung einer Einheit nicht an den Grenzen des Unternehmens enden. Die Integration bezieht sich infolgedessen im gleichen Maße auf einen innerbetrieblichen sowie auf einen zwischenbetrieblichen Kontext.

116

117

118

119 120 121

Vgl. Ferstl/Sinz (2001), S. 215-216. Frühere Ansätze fokussierten im Wesentlichen die innerbetrieblichen Prozesse (vgl. etwa Davenport/Short (1990), S. 11-20; Hammer (1990), S. 104-101; Davenport (1993)). Seit jüngerer Zeit wird jedoch auch den zwischenbetrieblichen Prozessen erhöhte Aufmerksamkeit geschenkt (vgl. etwa Steffen (2002), S. 3; Schissler et al. (2004), S. 1-19). Vgl. Schissler et al. (2004), S. 2-5. Hintergrund sind die Prinzipien der Organisation, gemäß derer die Arbeitsteilung und Spezialisierung zwar zu Produktivitätssteigerungen führt, gleichzeitig jedoch Ressourcen zur Abstimmung und zum Tausch zwischen den spezialisierten Bereichen aufgebracht werden müssen (vgl. Picot et al. (2005), S. 5). Vorstellbar in Form eines Produktionsplans eines Produzenten, anhand dessen sich für einen Lieferanten Liefertermine ergeben (vgl. Fleisch (2001), S. 100). Vgl. Scheckenbach (1997), S. 25; Schwinn/Schelp (2003), S. 237. Vgl. Mantel/Schissler (2002), S. 172. Vgl. Heilmann (1989), S. 47-48.

Grundlegende Begriffe

29

(1) unterbrochener Informationsfluss Unternehmen 1 Unternehmen 2 (z.B. Produzent) (z.B. Lieferant) Prozessschritt n

Prozessschritt n+1

(2) integrierter Informationsfluss Unternehmen 1 Unternehmen 2 (z.B. Produzent) (z.B. Lieferant) Prozessschritt n

Prozessschritt n+1

AS1 AS1

AS2

AS2

= Informationsfluss (z.B. Produktionsplan)

Abb. 2.1.2.2/1: Integration von Anwendungssystemen122

Zur Integrationscharakterisierung hat sich innerhalb der Wirtschaftsinformatik die Beschreibung ihrer organisatorischen Ausgestaltung verbreitet. Ein einheitliches Raster dafür hat sich bisher jedoch noch nicht herauskristallisiert.123 Trotz einer fehlenden Übereinkunft im Detail ist zur Charakterisierung der Integration die Verwendung der Merkmale Integrationsgegenstand, -richtung und -reichweite verbreitet.124 Integrationsgegenstände stellen Daten, Funktionen (Prozesse/Vorgänge) und Programme dar.125 Die Datenintegration zielt dabei auf eine (logische) Zusammenführung von Datenbeständen für eine wiederholte Verwendung bzw. gemeinsame Nutzung durch unterschiedliche Anwendungssysteme.126 Ermöglicht wird dies durch die Nutzung standardisierter Datenaustauschformate, die Schaffung von Schnittstellen zur gemeinsamen Datennutzung oder durch die Erstellung eines Unternehmensdatenmodells.127 Die Funktionsintegration bezieht sich auf die Zusammenfassung fachlich zusammengehörender Teilaufgaben (Tätigkeiten).128 Es wird dabei zwischen der aufgabenträgerorientierten und der aufgabenorientierten Funktionsintegration unterschieden.129 Erstere führt ehemals getrennte Teilaufgaben eines Aufgabenträgers an seinem Ar122 123

124

125 126 127 128 129

In Anlehnung an Fleisch (2001), S. 100. Vgl. Kaib (2002), S. 14 sowie im Detail Linß (1995), S. 7-17. Die Ansätze zur Beschreibung der Integration unterscheiden sich insbesondere durch ihre allgemeine Anwendbarkeit, die Anzahl und Unabhängigkeit der verwendeten Dimensionen zur Beschreibung sowie durch die Berücksichtigung eines Integrationsgrades. Vgl. Schumann (1992), S. 9-18; Mertens (2004), S. 1-8; Heilmann (1989), S. 48-49; Mertens et al. (2005), S. 7-11; Linß (1995), S. 17-27; Kaib (2002), S. 17-20; Schönherr/Gallas (2003), S. 129132; Müller (2005), S. 32-33. Vgl. Mertens (2004), S. 1-5. Vgl. Becker (1991), S. 166. Vgl. Linß (1995), S. 19-20. Vgl. Mertens et al. (2005), S. 7. Vgl. Ferstl/Sinz (2001), S. 221-222.

30

Grundlagen und Methodenanforderungen

beitsplatz zusammen. Letztere verkettet verschiedene Aufgaben zur Unterstützung von bereichsübergreifenden Arbeitsabläufen.130 Gegenstand der Programmintegration ist schließlich die Abstimmung von Programmbausteinen.131 Fokussiert wird dabei zum einen die Harmonisierung von Methoden – etwa zur Losgrößenbestimmung – innerhalb der Softwarebausteine sowie die Schaffung von Schnittstellen, die eine nahtlose Verknüpfung von Systemen ohne zusätzliche Konvertierungsarbeiten ermöglichen. Die drei skizzierten Integrationsgegenstände bauen aufeinander auf. Die Basis der Integration wird durch die Datenintegration und die damit verbundene Schaffung eines einheitlichen Datenbestandes gebildet.132 Darauf baut die Funktionsintegration auf.133 Ohne eine Zusammenführung der zugrunde liegenden Daten ist die Integration der Funktionen eines Aufgabenträgers oder Vorgangs nicht möglich.134 Die Programmintegration auf oberster Ebene zielt auf die nahtlose Verknüpfung von Anwendungssystemen etwa durch Programmbausteine (Komponenten) ab, über die sowohl die Daten- als auch die Funktionsintegration realisiert wird.135 Hintergrund ist die nötige Zusammenführung von relevanten Datenbeständen für die Zusammenfassung der Funktionen eines Aufgabenträgers sowie eines Vorgangs. Die Integration von Anwendungssystemen kann in horizontaler und in vertikaler Richtung erfolgen.136 Bei der horizontalen Integration steht die Wertschöpfungskette im Fokus der Betrachtung. Sie zielt auf die Verknüpfung von Anwendungssystemen entlang des Wertschöpfungsprozesses dem mit Ziel, künstliche Grenzen zwischen Aufgabenbereichen durch die Schaffung bzw. die Verkürzung von Kommunikationskanälen aufzuweichen.137 Die vertikale Integration bezieht sich hingegen auf die Versorgung der Planungs- und Kontrollsysteme mit den Daten aus den operativen Systemen.138 Somit werden im Rahmen der vertikalen Integration die Anwendungssysteme unterschiedlicher hierarchischer Ebenen verknüpft.

130

131

132 133 134

135 136 137 138

Vgl. Ferstl (1992), S. 15. Ist die Verkettung der Aufgaben stark an einem Vorgang orientiert, so wird diese auch als Vorgangs- bzw. Prozessintegration bezeichnet. Vgl. Schumann (1992), S. 7; Mertens (2004), S. 2-3. Zur Bedeutung von Schnittstellen bei der Integration auch Österle et al. (1991), S. 68-69. Vgl. Schumann (1992), S. 14-18. Vgl. Raasch (1991), S. 46. Vgl. Schissler et al. (2004), S. 16. Härder (1990), S. 265 versteht die Datenbasis aus dieser Perspektive als „Integrationsvehikel“. Vgl. Kaib (2002), S. 17. Vgl. Mertens (2004), S. 5; Linß (1995), S. 23-24; Heilmann (1989), 52-56. Vgl. Schumann (1992), S. 14. Vgl. Mertens (2005), S. 5.

Grundlegende Begriffe

31

Die Integrationsreichweite wird schließlich in die innerbetriebliche und die zwischenbetriebliche Integration unterteilt.139 Die innerbetriebliche Integration zielt der Bezeichnung entsprechend ausschließlich auf die Integration des Binnenbereichs eines Unternehmens. Sie kann sich lediglich auf einen Unternehmensbereich beschränken oder über verschiedenen Bereichen – innerhalb eines Standorts bis hin zur vollständigen Integration über verschiedene Standorte eines Unternehmens – hinweg erfolgen. Zu beachten ist jedoch die sich ergebende Komplexität und Unflexibilität vollständig integrierter Anwendungssysteme, so dass sie im praktischen Einsatz kaum Vorteile bergen.140 Die Integration der Anwendungssysteme zweier oder mehrerer rechtlich selbständiger Unternehmen wird als zwischenbetriebliche Integration bezeichnet. Ähnlich wie bei der innerbetrieblichen Integration kann die zwischenbetriebliche Integration lediglich zwischen verschiedenen Bereichen von zwei oder mehreren Unternehmen erfolgen, bis hin zur vollständigen Integration aller Anwendungssysteme verschiedner Unternehmen als theoretischer Fall. Zusammenfassend besteht somit das Integrationsverständnis innerhalb der vorliegenden Untersuchung aus sieben Komponenten, die drei unterschiedlichen Integrationsdimensionen zugeordnet sind. In Abb. 2.1.2.2/2 ist das Integrationsverständnis graphisch dargestellt.

Dimensionen

Komponenten 1

A

Integrationsgegenstand

B

Integrationsrichtung

C

Integrationsreichweite

2 Daten

3

Funktionen

Programme

5

4

horizontal

vertikal 7

6 innerbetrieblich

zwischenbetrieblich

Abb. 2.1.2.2/2: Integrationsmerkmale zur Übersicht141

Die Vorstellung des Grundverständnisses der Integration wurde bisher noch weitgehend unabhängig von der Frage behandelt, inwiefern es sich um die Integration innerhalb eines Unternehmens oder um die Integration in einem Unternehmensnetz139

140 141

Vgl hierzu und im Folgenden Schumann (1992), S. 11-14; Linß (1995), S. 25-27; Mertens (2004), S. 5-8. Vgl. Mertens (2004), S. 7. Vgl. Linß (2000), S. 18.

32

Grundlagen und Methodenanforderungen

werk handelt. Im Folgenden sollen somit Architekturen integrierter Anwendungssysteme für Unternehmensnetzwerke vorgestellt werden. 2.1.2.3

Netzwerkspezifische Integrationsarchitekturen

Im vorangestellten Abschnitt wurden die möglichen Integrationsgegenstände Daten, Funktionen und Programme vorgestellt. Anhand dieser lassen sich drei grundlegende Architekturen zur zwischenbetrieblichen Integration ableiten.142 Unterschieden werden (1) Daten-Sharing zur reinen Integration der Daten, (2) ApplikationsKommunikation, die sowohl die Integration von Daten als auch von Funktionen ermöglicht, und schließlich das (3) Applikations-Sharing, bei dem die Integration von Daten, Funktionen und Programmen realisierbar ist. Abb. 2.1.2.3/1 zeigt schematisch die drei grundlegenden Varianten der Integration für eine aus zwei Unternehmen bestehende zwischenbetriebliche Kooperation. Im Folgenden werden diese Architekturen skizziert sowie verbreitete Integrationstechnologien zu ihrer Realisierung vorgestellt. Unternehmensnetzwerk 1

DatenSharing DB UNW

U1

2

AS 1

ApplikationsKommunikation

U2 AS 2

AS UNW 3

ApplikationsSharing

Abb. 2.1.2.3/1: Grundlegende Integrationsarchitekturen für Unternehmensnetzwerke

Daten-Sharing Auf einfachster Ebene der Integrationsgegenstände wurde die Datenintegration aufgeführt. In einem zwischenbetrieblichen Kontext lässt sich diese durch die Architekturform Daten-Sharing realisieren.143 Im Rahmen des Daten-Sharings greifen die Partner eines Unternehmensnetzwerks mit ihren eigenen Anwendungssystemen auf 142 143

Etwa Arnold et al. (1995), S. 15-16; Schräder (1996), S. 116-118; Mertens et al. (1998), 87-84. Vgl. Sieber (2003), S. 195.

Grundlegende Begriffe

33

einen zentral verwalteten Datenbestand zu.144 Voraussetzung hierfür ist ein kompatibles Datenmodell der Partnerunternehmen mit dem zentralen Datenbestand. Dies kann durch die Verwendung standardisierter Formate zur Kopplung der Anwendungssysteme von Partnerunternehmen mit der Datenbasis ermöglicht werden. Zu berücksichtigen ist beim Daten-Sharing, dass per Definition eine Vielzahl von Partnern auf den gleichen Datenbestand zugreift. Daher bedarf es bei der Implementierung einer unterschiedlichen Abstufung von Zugriffsrechten der Partnerunternehmen.145 Ein wesentlicher Vorteil des Daten-Sharings liegt in der zentralen Datenlagerung, die zu einer erhöhten Datenintegrität führt. Konkret im Netzwerk beschränkt sich der Einsatz nach Sieber typischerweise jedoch auf einen teilautomatisierten, asynchronen Austausch bzw. gegenseitigen Zugriff projektspezifischer Daten eines Netzwerks.146 Realisiert wird die Integration des Daten-Sharings unter dem Einsatz einer zentralen (webbasierten) Datenbank.147 Ableiten lässt sich dieser Integrationsansatz aus der innerbetrieblichen Datenintegration insbesondere anhand des Konzepts eines DataWarehouse.148 Gespeist wird die zu schaffende einheitliche Datenbasis aus den unternehmensnetzwerksinternen sowie bei Bedarf -externen Datenquellen.149 Dazu ist die Extraktion der betroffenen Daten aus den Datenquellen notwendig und – aufgrund bestehender semantischer Abweichungen zwischen den Quellen – meist eine Transformation bevor die Daten in die Datenbasis geladen werden können.150 Weitgehend unabhängig von der Lokalisierung der Datenbasis sowie der Datenquellen151 erfolgt das Laden der Daten lokal oder über das Internet.152 Aufgrund der physikalischen Verteilung der Partnerunternehmen wird typischerweise über das Internet auf die zentrale Datenbasis zugegriffen. Abhängig von der Datenstruktur der zentralen

144 145 146 147 148

149 150

151

152

Vgl. Arnold et al. (1995), S. 15. Vgl. Ma et al. (2002), S. 133. Vgl. Sieber (2003), S. 195. Vgl. Hsieh/Lin (2003), S. 3-6. Das Ziel eines Data-Warehouse liegt in der Schaffung einer zentralen Datenbasis aus den operativen und externen Daten eines Unternehmens, im ursprünglichen Ansatz lediglich beschränkt auf die Unterstützung von Planungs- und Kontrollaufgaben der Unternehmensführung im Sinne einer vertikale Datenintegration (vgl. Mucksch/Behme (2000)). Durch ihre Erweiterung um operative Data-Stores (vgl. etwa Winter (2000), S. 23-40; Auth/Frie (2001)) und die Verknüpfung mit EAISystemen (vgl. Jung (2001), S. 35-37) werden sie aktuell auch für den Einsatz im operativen Bereich (im Sinne einer horizontalen Datenintegration) diskutiert. Vgl. Mertens (1999), S. 413. Dieser Extraktions-, Transformations- und Ladevorgang wird als ETL-Prozess bezeichnet und u. U. durch spezielle Software unterstützt. z. B. kann die Datenbasis lokal bei einem (fokalen) Partner oder „im Internet“ auf den Servern eines Webhosts liegen. Ebenfalls können je nach Szenario die Datenquellen zentral und damit im gleichen Unternehmen wie die Datenbasis oder verteilt über die Partner des Netzwerks bzw. außerhalb des Netzwerks im Falle von externen Daten liegen. Vgl. Schwinn/Schelp (2003), S. 233-236.

34

Grundlagen und Methodenanforderungen

Datenbasis bedarf es für die Nutzung durch die Partner u. U. einer weiteren Transformation, die sich jedoch durch den Einsatz von standardisierten Datenaustauschformaten vermindern lässt. Ebenfalls können die Partner je nach Ausgestaltung die zentral erhaltenen Daten in ihren Anwendungssystemen zwischenspeichern. Vereinfacht ist die Integrationstechnologie einer zentralen webbasierten Datenbank in Abb. 2.1.2.3/2 graphisch dargestellt.153 Unternehmensnetzwerk

Partner 1 DB 1

externe Datenquelle

Partner 1 AS 2

Internetschnittstelle

ggf. ETLProzesse

Partner 2 AS 3 Partner 2 AS 1

Datenherkunft

zentrale (webbasierte) Datenbasis

Partner 3 AS 4

Datennutzung

Abb. 2.1.2.3/2: Zentrale Datenbank zum Daten-Sharing154

Applikations-Kommunikation Mit der so genannten Applikations-Kommunikation als zweite Architekturform zur Integration von Anwendungssystemen in Unternehmensnetzwerken lässt sich neben der Daten- ebenfalls die Funktionsintegration ermöglichen. Die zu integrierenden Anwendungssysteme bleiben allerdings weitgehend voneinander separiert. Die Kommunikation wird lediglich durch die Schaffung von einheitlichen Kommunikationsschnittstellen und -standards ermöglicht.155 Drei grundsätzliche Klassen von Standards kommen dabei zum Einsatz, die sich gemäß der Kommunikationsebenen der Semiotik unterscheiden lassen.156 Ausgangspunkt ist die Übertragung der Daten zwischen den an der ApplikationsKommunikation beteiligten Anwendungssystemen. Dabei kommen typischerweise Standards des Internets zum Einsatz, die auf technischer Ebene das Verfahren und

153 154 155 156

Für ein Fallbeispiel vgl. Kapitel 3.2.1 In Anlehnung an Halaris/Kerridge (2003), S. 257. Siehe auch Hsieh/Lin (2003), S. 5. Vgl. Schräder (1996), S. 117. Zur Semiotik vgl. Kapitel 2.1.2.1.

Grundlegende Begriffe

35

das Vorgehen des Datenaustauschs definieren.157 Verbreitete Standards dazu stellen etwa das Transmission Control Protocol (TCP), Internet Protocol (IP) oder Simple Mail Protocol (SMTP) dar.158 Bei der Applikations-Kommunikation sind des Weiteren Standards zur Definition des Aufbaus der auszutauschenden Daten auf syntaktischer Ebene von Bedeutung.159 Ermöglichen lässt sich dies durch weitgehend standardisierte Datenformate (etwa EDI) oder branchen- oder prozessspezifische Standards zur Datenbeschreibung, die etwa mit diversen XML-Standards realisiert sind. Aufgrund der fortgeschrittenen Entwicklung von Standards der technischen und syntaktischen Ebene kann die reine Kommunikation zwischen Anwendungssystemen als gelöst betrachtet werden.160 Weniger fortgeschritten sind hingegen Standards, die Rückschlüsse auf die Bedeutung der übertragenen Daten (im Sinne von Informationen) zulassen.161 Diese sind jedoch für n:m-Beziehungen, wie sie in Netzwerken typischerweise anzutreffen sind, sowie für die Automatisierung vollständiger Abläufe besonders relevant.162 Entsprechende Ansätze liefern Standards der höheren Ebenen der Semiotik, deren Entwicklung jedoch nicht im gleichen Maße fortgeschritten ist, wie bei den Standards der technischen und syntaktischen Ebene.163 Grundsätzlich zielen jedoch Standards der semantischen Ebene auf die Bedeutung einer übertragenen Nachricht ab. Damit lassen sich Nachrichtentypen wie Lieferschein, Angebot oder Rechnung unterscheiden.164 Schließlich bedarf es zur Automatisierung von Abläufen im Rahmen einer Funktionsintegration Standards auf der pragmatischen Ebene. Rückschlüsse auf die Absicht einer erhaltenen Nachricht müssen diese zulassen, um darauf individuell und adäquat reagieren zu können. Zwei grundsätzliche Varianten bezüglich der Applikations-Kommunikation lassen sich unterscheiden. Die Punkt-zu-Punkt-Integration als erste Variante stammt aus den Ursprüngen der Anwendungssystemintegration. Charakterisiert ist diese Integrationstechnologie durch die Etablierung einer Vielzahl von spezifischen Schnittstellen zur Kommunikation zwischen jeweils zwei gleichberechtigten Anwendungssystemen (vgl. Abb. 2.1.2.3/3). Zur Integration vieler Anwendungssysteme ist entsprechend eine Vielzahl von Schnittstellen zu etablieren. Das Ergebnis solcher Anwendungssystem157

158 159 160 161 162

163 164

Diese Standards sind auch für die anderen beschrieben Architekturen im Rahmen des Datenaustauschs von Bedeutung. Vgl. Mertens et al. (2005), S. 44-45. Vgl. Voigtmann/Zeller (2002), S. 17. Vgl. Fleisch (2001), S. 132. Vgl. Kapitel 2.1.2.1. Hintergrund ist die erschwerte Vermeidung von Doppeldeutigkeiten bei einer steigenden Anzahl an Beteiligten. Vgl. Voigtmann/Zeller (2003), S. 223. Vgl. Voigtmann/Zeller (2002), S. 17.

36

Grundlagen und Methodenanforderungen

landschaften ist typischerweise vergleichbar. Aufgrund der schwer zu überschauenden Anzahl an Schnittstellen sind sie regelmäßig durch eine hohe Komplexität und Starrheit gekennzeichnet.165 Problematisch stellt sich insbesondere der Austausch eines einzelnen Systems dar, da dieser mitunter zur Entwicklung einer erheblichen Anzahl von neuen Schnittstellen führt.166 Unternehmensnetzwerk

Partner 1 AS 1

Partner 3 AS 3

Partner 2 AS 2

Partner 4 AS 4

= proprietäre Schnittstelle

Abb. 2.1.2.3/3: Punkt-zu-Punkt-Integration zur Applikations-Kommunikation167

Unterschiedlich enge Kopplungen sind im Rahmen der Punkt-zu-Punkt-Integration aufzufinden. Äußerst lose sind die Systeme gekoppelt, wenn zu ihrer Kommunikation manuelle Bearbeitungsschritte nötig sind.168 Bei solch gekoppelten Systemlandschaften wird meist auf bestehende Systemkomponenten unter Verwendung von mehrheitlich proprietären Kommunikationsstandards zurückgegriffen. Lediglich die Standards der untersten sowie bedingt der zweiten Kommunikationsebene werden bei einer solchen Integrationslösung eingesetzt.169 Beim Ziel einer weitgehend automatischen Abwicklung der Applikations-Kommunikation im Rahmen der Punkt-zu-PunktIntegration ist hingegen eine engere Kopplung nötig. Diese zeichnet sich durch den 165

166

167 168

169

Vgl. Schönherr/Gallas (2003), S. 126-127. Plakativ beschrieben durch den Begriff einer „Spaghetti-Integration“ (vgl. Keller (2002), S. 23). Der Austausch des AS 3 von Partner 3 in Abb. 2.1.2.3/3 würde etwa zur Entwicklung von vier neuen Schnittstellen führen (vgl. Kaib (2002), S. 68). In Anlehnung an Winkeler et al. (2001), S. 6. Vgl. Etwa wenn im Rahmen der Datenübertragung manuelle Eingriffe nötig sind. Vorstellbar für typischen Fall bei dem Daten eines Ursprungsystems zunächst exportiert, im Anschluss per Email übertragen und schließlich in das Empfängersystem importiert werden (vgl. Linß (1995), S. 19-20; Emmelhainz (1990), S. 5-7). Typisches Beispiel ist die Ausgabe von Daten eines Ursprungsystems in ein unspezifisches Datenformat, wie etwa in Form einer Text-Datei, deren Übertragung per Email mit anschließendem Import über im Empfängersystem vorhandene Schnittstellen.

Grundlegende Begriffe

37

Rückgriff auf spezifische Transformations- und Kommunikationsmodule zwischen den Anwendungssystemen sowie auf vorab fest definierte Ausgestaltung bzw. Nutzung eines standardisierten Formats zur Kommunikation aus.170 Entsprechend werden bei dieser engeren Variante Standards höher Kommunikationsebenen eingesetzt. Typische Beispiele in Netzwerken finden sich dafür in Form auf XMLbasierenden Formaten kommunizierende Anwendungssysteme.171 Die hohe Schnittstellenanzahl führte im Laufe der Zeit zur Entwicklung einer zweiten Variante der Applikations-Kommunikation in Form von middlewarebasierten Integrationstechnologien und ihrer jüngsten Ausprägungsvariante Enterprise Application Integration (EAI). Im Kern kennzeichnen sich diese Ansätze durch die Verwendung einer (zentralen) Integrationsplattform. Diese fungiert als einheitliche Kommunikationsschnittstelle, mit der sämtliche zu integrierende Anwendungssysteme verbunden sind.172 Mit einer solchen Architektur lässt sich die Anzahl der zu entwickelnden und wartenden Schnittstellen auf ein Minimum reduzieren.173 Zwei wesentliche Varianten sind verbreitet.174 Bei der zentralen Variante bildet die Integrationsplattform das (logische) Zentrum der Architektur, um das die gekoppelten Systeme – sinnbildlich gesprochen – sternförmig angeordnet sind. Beim Einsatz innerhalb eines Unternehmensnetzwerks sind die zu koppelnden Systeme dabei über Internetschnittstellen mit der Integrationsplattform zu verknüpfen. Bei der so genannten Bus- oder verteilten Variante hingegen ist die Integrationsplattform auf die zu integrierenden Systeme verteilt. Über Internetschnittstellen findet beim Einsatz in einem Unternehmensnetzwerk dabei ebenfalls die Kommunikation zwischen den zu koppelnden Anwendungssystemen statt (vgl. Abb. 2.1.2.3/4).

170 171 172 173

174

Vgl. Burghardt (2003), S. 20-23. Vgl. Hess (2002a), S. 341. Vgl. Dangelmaier et al. (2002), S. 62. Ist bei einer Punkt-zu-Punkt-integrierten Systemlandschaft theoretisch die Entwicklung und Wartung von A(n²) Schnittstellen nötig, so lässt sich diese Anzahl auf maximal A(n) Schnittstellen bei einer Integration über eine zentrale Plattform reduzieren, wobei „A“ für ein zu koppelndes Anwendungssystem und n für deren Anzahl steht (vgl. Keller (2002), S. 23-24). Vgl. Ring (2000), S. 26.

38

Grundlagen und Methodenanforderungen

Unternehmensnetzwerk

Unternehmensnetzwerk AS / Integrationsplattform 1 Partner 1

Internetschnittstellen

Partner 1 AS 1

Partner 3 AS 3

AS / Integrationsplattform 3 Partner 3

Internetschnittstellen

zentrale Integrationsplattform

Internet

Internetschnittstellen

Partner 2 AS 2

Internetschnittstellen zentrale Architektur

Partner 4 AS 4

AS / Integrationsplattform 2 Partner 2

AS / Integrationsplattform 4 Partner 4

verteilte Architektur

Abb. 2.1.2.3/4: Middleware-basierte Integrationstechnologien zur Applikations-Kommunikation

Während middlewarebasierte Ansätze ursprünglich lediglich auf die Integration von Daten zielten, gehen aktuell diskutierte EAI-basierte Ansätze darüber hinaus.175 Mit diesen lässt sich zusätzlich eine weitgehend nahtlose Abwicklung vollständiger Vorgänge realisieren. Dazu ist innerhalb der EAI-Architektur ein spezieller Dienst (Process Service) enthalten, mittels dem sich Sequenzen von Datenübertragungen zwischen den gekoppelten Systemen anhand eines vordefinierten Ablaufs automatisch ausführen lassen.176

Applikations-Sharing Das Applikations-Sharing ist schließlich die dritte Architektur zur Anwendungssystemintegration in Unternehmensnetzwerken. Ihr Kennzeichen liegt in der gemeinsamen Nutzung eines zentralen Anwendungssystems durch mehrere Partnerunternehmen eines Netzwerks.177 Die darin integrierten Daten und Funktionen decken typischerweise vollständige Vorgänge eines Netzwerks ab. Parallelen zu diesem zwischenbetrieblichen Applikations-Sharing finden sich in der innerbetrieblichen Integration. Vorangetrieben durch Softwareanbieter, wie SAP und Baan, verbreiteten sich Ende der 1980er Jahre großintegrierte Anwendungssysteme (ERP-Systeme) mit dem Ziel, unternehmensweite Prozesse mit einem einzigen Anwendungssystem zu unterstützen.178 Im Kern handelt es sich dabei um monolithische Softwaresysteme, die sich aus transaktionsorientierten Softwarebausteinen (gegliederte Module) zu-

175 176 177 178

Vgl. Kaib (2002), S. 86-87. Vgl. Puschmann/Alt (2004), S. 105-116. Vgl. Mertens et al. (1998), S. 79-81; Schräder (1996), S. 117-118. Vgl. Kumar/van Hillegersberg (2000), S. 23-24.

Grundlegende Begriffe

39

sammensetzen und auf eine einheitliche Datenbasis zugreifen.179 Werden großintegrierte Anwendungssysteme von Drittanbietern bereitgestellt, liegt ihnen in der Regel ein eigenes Referenzmodell mit einer idealtypischen Prozessausgestaltung zugrunde, welches der Anbieter der Systeme unternehmensspezifisch anpasst (Customizing). Im Rahmen des zwischenbetrieblichen Applikations-Sharing lassen sich zwei grundlegende Integrationstechnologien unterscheiden. Zum einen finden sich in Anlehnung an die innerbetrieblich verwendeten großintegrierten Anwendungssysteme spezielle webbasierte Ausgestaltungsvarianten, die vollständige zwischenbetriebliche Prozesse unterstützen. Dabei sind die Anwendungsfunktionen, die typischerweise aus einzelnen Modulen zusammengesetzt sind, sowie die Datenhaltung zentral und über das Internet erreichbar. Aufseiten der Partnerunternehmen bedarf es lediglich einer Internetschnittstelle (unter Verwendung eines Webbrowsers) für den Anwendungszugriff.180 Entsprechend finden sich tendenziell keine Daten und Funktionen der Anwendung aufseiten der Partnerunternehmen.181 Ein Beispiel für eine derartige Integrationsarchitektur findet sich in Form des vom Institut für Wirtschaftsinformatik und Neue Medien der Universität München in Zusammenarbeit mit dem Institut für Wirtschaftsinformatik II der Universität Göttingen im Rahmen eines Forschungsprojekts entwickelten VICOPLAN. Dieses webbasierte Anwendungssystem unterstützt typische Netzwerkprozesse auf auftragsbezogener und -übergreifender Ebene und wird von den Netzwerkpartnern lediglich über einen Internetbrowser gesteuert.182 Die zweite Variante des Applikations-Sharings in Netzwerken genießt derzeit unter dem Stichwort WebService eine erhöhte Aufmerksamkeit.183 Zu verstehen sind WebServices als verteilte, lose gekoppelte und wieder verwendbare SoftwareKomponenten, auf die sich über Standard-Internetprotokolle zugreifen lässt.184 Vereinfachend ist ein WebService eine gekapselte Anwendungskomponente, deren Funktionalität über eine einfache Internetschnittstelle und standardisierte Protokolle aufgerufen werden kann, die diese durchführt und sich daraus ergebene Informationen zurücksendet. Derzeit unterstützen WebServices primär einfache Funktionen wie z. B. Datenbankabfragen.185 Durch ihre Verknüpfung zu so genannten SuperServices lassen sich mit ihnen jedoch umfassende Prozesse weitgehend automatisch realisie179

180 181 182 183 184 185

Vgl. Kaib (2002), S. 56. Insofern handelt es sich beim Applikations-Sharing um Programmintegration, welche als Abstimmung von Programmbausteinen zur u. a. nahtlosen Verknüpfung von Systemen definiert wurde (vgl. Kapitel 2.1.2.2 sowie Schumann (1992), S. 7). Vgl. Ho/Lin (2004), S. 3737-3739. Vgl. Katzy (2005), S. 49; Hess (2002b). Vgl. Schumann et al. (2004), S. 19-56. Vgl. etwa Daniel et al. (2004), Burghardt (2003), S. 25-35. Vgl. Schönherr/Gallas (2003), S. 133. Vgl. Greiner/Rahm (2004), S. 11.

40

Grundlagen und Methodenanforderungen

ren.186 Im Rahmen des Applikations-Sharings in Unternehmensnetzwerken nutzen die Partnerunternehmen einen Web- bzw. SuperService über ihre eigenen Anwendungssysteme. Der Service wird dabei von einem Partner des Netzwerks bzw. einen externen Anbieter angeboten.187 In Abb. 2.1.2.3/5 sind die Varianten des Applikations-Sharings vereinfacht zur Übersicht dargestellt. Unternehmensnetzwerk Partner 1 Webclient 1

Internetschnittstellen

Unternehmensnetzwerk Partner 3 Webclient 3

Internetschnittstellen

Partner 3 AS 3

Partner 1 AS 1 modulbasierte Anwendungsfunktionen

M1 M… Mn

SuperService (zusammengesetzt aus WebServices)

WS1

WS…

WSn

Datenbasis

Partner 2 Webclient 2

Internetschnittstellen

Partner 4 Webclient 4

Partner 2 AS 2

intrgriertes (Web-)Anwendungssytem

Internetschnittstellen

Partner 4 AS 4

WebService-Architektur

Abb. 2.1.2.3/5: Integrierte Anwendungssysteme und WebServices zum Applikations-Sharing

2.1.3 Method Engineering als Analyseansatz Verbreitete betriebliche Anwendungssysteme sind typischerweise durch einen kaum überschaubaren Funktionsumfang geprägt. Eindrucksvoll lässt sich dies anhand der oben bereits skizzierte Enterprise Resource Planning-Systeme (ERP-Systeme) veranschaulichen.188 Wie beschrieben unterstützen sie aufgrund ihres mächtigen Funktionsumfangs vollständige Unternehmensprozesse. Dieser enorme Funktionsumfang geht allerdings mit einer zunehmenden Komplexität der Systementwicklung einher.189 Ansätze der strukturierten Anwendungssystementwicklung sollen dieser Komplexität entgegengetreten. Dazu wurden aus Wissenschaft und Praxis bis heute unter dem Schlagwort „Software Engineering“ eine Viel186 187

188 189

Vgl. Burghardt et al. (2003), S. 61-62. Auf dem ersten Blick ähnelt die so erhaltene Architektur der im Rahmen der ApplikationsKommunikation vorgestellten zentralen middelwarebasierten Integrationstechnologie. Ein wesentlicher Unterschied liegt dennoch vor. So wird die zentrale Integrationsplattform der middlewarebasierten Variante primär als Kommunikationsschnittstelle eingesetzt, wohingegen bei der auf WebServices basierenden Variante eine Applikationsfunktionalität (Service) bereitgestellt wird. Vgl. auch Stahlknecht/Hasenkamp (1999), S. 344. Vgl. Heym (1995), S. 1.

Grundlegende Begriffe

41

zahl von Forschungsansätzen entwickelt, die auf eine „zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die ingenieurmäßige Entwicklung, Anwendung und Wartung von Softwareprodukten“190 zielen. Die zahllosen Ansätze innerhalb des Software Engineerings unterscheiden sich jedoch mitunter stark. Daraus ergibt sich die Frage, welche Entwurfsmethode für die Entwicklung eines Anwendungssystems für ein konkretes Einsatzszenario besonders geeignet ist.191 Das Method Engineering als Teilgebiet des Software Engineerings konzentriert sich auf die systematische und strukturierte Beschreibung, Modifikation und Anpassung von Software-Entwicklungsmethoden.192 Dies erfolgt im Kern durch die Strukturierung der zu untersuchenden Methoden in fünf zentrale Methodenkomponenten, die sämtliche Methodenbestandteile systematisch erfassen.193 Die vorgenommene Strukturierung sowie die Analyse der Beziehungen zwischen den Methodenkomponenten ermöglichen den Vergleich und damit die Ermittlung von Gemeinsamkeiten und Unterschiedenen zwischen so untersuchten Methoden. Der Einsatzbereich des Method Engineerings ist jedoch nicht ausschließlich auf Methodenanalyse bzw. -entwicklung des Software Engineerings beschränkt. Vielmehr lässt sich die angedeutete Strukturierung und die anschließende Untersuchung generell auf (wirtschaftswissenschaftliche) nicht-mathematisch-heuristische Methoden übertragen und ermöglicht damit ebenfalls deren umfassende Vergleichbarkeit und Weiterentwicklung (vgl. Abb. 2.1.3/1).194 Vor allem in Forschungsarbeiten zum Informations- und Prozessmanagement findet sich das Method Engineering daher vermehrt.

190 191 192 193 194

Grob et al. (2004), S. 189. Vgl. Odell (1996), S. 1. Vgl. Gutzwiller (1994), S. 11. Vgl. Brenner (1995), S. 10. So etwa in den Arbeiten geschehen von u. a. Alt et al. (2004), S. 257-281; Kremer (2004); Benz (2001); Hess (1996); Brenner (1995).

42

Grundlagen und Methodenanforderungen

Methodenvergleich und -bewertung MethodenWissensakquisition

rechnergestützte Methodendokumentation

rechnergestütztes Lernen / Training

Methodenspezifikation und -entwicklung

MethodenEngineering

Methodenintegration und -anpassung

Meta-Case SoftwareProzessmodellierung

Abb. 2.1.3/1: Anwendungsgebiete des Method Engineering195

Wie oben skizziert gliedert das Method Engineering die zu untersuchenden Methoden in fünf Komponenten. Dabei wird unterschieden in (1) Aktivitäten, deren Resultate festgehalten in Form von (2) Ergebnissen, die zu deren Erhalt eingesetzten (3) Techniken, die (4) Rollen der beteiligten Akteure, welche die Techniken umsetzen, sowie ein übergeordnetes (5) Metamodell. Die Komponenten des Method Engineerings werden im Folgenden kurz vorgestellt:196 1. Aktivitäten: Unter Aktivitäten werden Vorgehensschritte gefasst, die einer Methode zugrunde liegen und bei ihrer Durchführung zu durchlaufen sind. Ziel von Aktivitäten ist der Erhalt von Ergebnissen. Diese können wiederum als Grundlage für weitere Aktivitäten Verwendung finden. Eine Aktivität lässt sich in verschiedene Sub-Aktivitäten unterteilen. Deren Zugehörigkeit zu jeweils einer übergeordneten Aktivität lässt Aktivitäten-Hierarchien entstehen. Werden Aktivitäten in eine chronologische Reihenfolge gebracht, so handelt es sich um eine Ablauffolge. Wird diese in ihrer Gesamtheit betrachtet und folglich alle Aktivitäten einer Methode einbezogen, so wird dies unter den Begriff Vorgehensmodell gefasst. 2. Ergebnisse: Aktivitäten einer Methode führen zu Zwischenresultaten bzw. einem Endresultat. Diese treten in Form von Texten, Darstellungen, Tabellen, Grafiken etc. auf. Ergebnisse als Output einer Aktivität stellen wiederum meist einen Input für eine oder mehrere nachfolgende Aktivitäten dar, die diese modifizieren oder weitere Ergebnisse produzieren. Ähnlich wie Aktivitäten sind ebenfalls Ergebnisse in Teilergebnisse zerlegbar. Die Zusammenfassung

195 196

Vgl. Heym (1993), S. 5. Vgl. im Folgenden Gutzwiller (1994), S. 11-39.

Grundlegende Begriffe

43

sämtlicher Ergebnisse einer Methode wird als Ergebnisdokument oder Dokumentationsmodell bezeichnet. 3. Techniken: Techniken sind detaillierte Anweisungen, die zum Erhalt von Ergebnisdokumenten führen. Im Vergleich zu einer groben Strukturierung durch Aktivitäten beinhalten Techniken genaue Vorgehenshinweise, die auf den Erhalt eines Ergebnisses abzielen. Im Gegensatz zu Aktivitäten, die vereinfachend gesprochen Rückschlüsse auf das „Was“ einer Methode zulassen, lässt sich anhand von Techniken detailliert das „Wie“ entnehmen. 4. Rollen: Aktivitäten bzw. Techniken werden von Akteuren durchgeführt. Sie nehmen dabei spezifische Rollen anhand des ihnen zugeordneten Bündels an Aktivitäten ein. Typische Rollen sind etwa bei einem Softwareprojekt Projektleiter, Qualitätssicherer oder Entwickler. Entsprechend der zugrunde liegenden Rolle sind Akteure an einer Aktivität unterschiedlich beteiligt. Dabei lässt sich insbesondere zwischen „entscheidend“, „verantwortlich“ oder „unterstützend“ unterscheiden. 5. Metamodell: Ein Metamodell zeigt die Gestaltungsobjekte der Methode sowie deren untereinander bestehenden Beziehungen. Dargestellt wird es typischerweise in Form eines Datenmodells bestehend aus Entitäten, die die Gestaltungsobjekte und ihren Beziehungen zueinander symbolisieren. Zur Komplexitätsreduzierung und vereinfachten Nachvollziehbarkeit wird jedoch meist auf die vollständige Darstellung sämtlicher atomisierter Bestandteile der Entwurfsergebnisse verzichtet. Vielmehr wird sich bei der graphischen Darstellung des Datenmodells typischerweise lediglich auf die zentralen Entitätstypen beschränkt. Die Darstellung von Metamodellen erfolgt im Rahmen der Untersuchung in Form eines vereinfachten Entitiy-Relationship-Diagramms.197 Dabei verkörpern die Knoten (als Rechtecke dargestellt) sämtliche Gestaltungsobjekte einer Methode, wie beispielsweise Aktivitäten, organisatorische Einheiten, etc. Die Kanten zwischen den Knoten hingegen stellen hingegen die Beziehungen zwischen den methodischen Gestaltungsobjekten dar. Zusätzlich erleichtern die Pfeile der Kanten die Leserichtung (vgl. Abb. 2.1.3/2).198 Vereinfacht dargestellt sind diese ER-Diagramme im Hinblick auf den Verzicht des Verweises auf Kardinalitäten und Attribute der Gestaltungsobjekte.199

197 198 199

Vgl. Chen (1976) sowie Gassner (1996), S. 40-41; Hess (1996), S. 33. Vgl. Österle (1995), S. 187-195; Brenner (1995), S. 11-12. Attribute dienen zur genaueren Beschreibung der Gestaltungsobjekte. Mittels Kardinalitäten können ferner viele weitere Gestaltungsobjekte mit einem bestimmten Gestaltungsobjekt in Beziehung stehen (vgl. Balzert (2000), S. 166 sowie 187-188).

44

Grundlagen und Methodenanforderungen

Allgemeines Darstellung eines ER-Diagramms Beziehung Gestaltungsobjekt 1

Gestaltungsobjekt 2

Beispielhafter Ausschnitt eines ER-Diagramms Organsiationseinheit

nimmt wahr

Aufgabe

Abb. 2.1.3/2: ER-Diagramm zur Abbildung eins Metamodells

In der Abb. 2.1.3/3 sind die skizzierten Komponenten sowie ihre Zusammenhänge überblicksartige dargestellt. Aktivitäten durchlaufen eine bestimmte Ablauffolge (Vorgehensmodell)

Ergebnisse sind hierarchisch strukturiert

Ergebnis

Ein Metamodell ist ein konzeptuelles (Daten-) Modell für Ergebnisse

Metamodell

Aktivitäten generieren und benutzen Ergebnisse

Aktivitäten sind hierarchisch strukturiert

Aktivität

Mitglieder von Organisationen mit spezifischen Rollen führen Aktivitäten aus und entwerfen sie

Techniken liefern Anweisungen für die Erstellung von Ergebnisdokumenten

Technik

Rolle

Abb. 2.1.3/3: Komponenten des Method Engineerings200

2.2

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

Um das Ziel der vorliegenden Untersuchung in Form eines Ansatzes zur Integrationsplanung und -bewertung in Unternehmensnetzwerken zu ermöglichen, stellt dieses Kapitel explorative Fallstudien der Integration in Unternehmensnetzwerken vor. Anhand dieser sollen Anforderungen und später bestehende Lücken innerhalb der Integrationsmethoden aus der Literatur im Hinblick auf netzwerkspezifische Besonderheiten erarbeitet werden. Zum anderen kommt ihnen im weiteren Verlauf der Untersuchung eine Rolle als Vorlage und Baukasten des entwickelten Methodenansatzes für Unternehmensnetzwerke zu. Demnach erhalten die Fallstudien einen Dokumentations- und Beispielcharakter des konkret untersuchten Objektbereichs.

200

In Anlehnung an Winter/Strauch (2004), S. 1361; Alt et al. (2004), S. 260.

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

45

Kapitel 3.2.1 geht zunächst auf die Auswahl der erhobenen Fallstudien ein. Im Anschluss stellt Kapitel 3.2.2 die jeweiligen Fallstudien anhand der Komponenten des Method Engineerings vor. Kapitel 3.2.3 stellt schließlich die Fallstudien zusammenfassend gegenüber. 2.2.1 Fallstudienauswahl und Analysevorgehen Wie beschrieben finden sich innerhalb der Forschung derzeit noch keine Ansätze, welche die Frage der Integration von Anwendungssystemen in Unternehmensnetzwerken umfassend behandeln. Lediglich im Ansatz lassen sich Hinweise aus den bestehenden Integrationsmethoden, wie etwa aus der Beschreibung der zwischenbetrieblichen Integration, auf Unternehmensnetzwerke übertragen. Eine zusammenhängende Konzeption ist hingegen nicht auffindbar. Des Weiteren ist empirisches Datenmaterial zum Integrationsvorgehen in Unternehmensnetzwerken innerhalb der WI-nahen Forschung kaum vorhanden. Vielmehr zielen die verbreiteten Fallstudien auf die tatsächliche Ausgestaltung einer integrierten Systemlandschaft und blenden den Weg zu dieser typischerweise aus.201 Aufgrund der somit fehlenden konzeptionellen sowie Datenbasis dieses Forschungsgebiets, bieten sich insbesondere Fallstudien zur Ableitung erster explorativer Erkenntnisse an.202 Fallstudien lassen sich in Form einer Einzel- oder Mehrfachuntersuchung durchführen. Die Einzeluntersuchung ist zu wählen, wenn der Untersuchungsgegenstand nur selten anzutreffen bzw. die Durchführung – etwa aufgrund der Komplexität – mit einem erheblichen Aufwand verbunden ist.203 Ist dies nicht der Fall, sollte auf Mehrfachstudien zurückgegriffen werden, die ein umfassenderes Bild des Untersuchungsausschnitts sowie erste Verifizierungen oder Falsifizierungen der abgeleiteten Aussagen ermöglichen.204 Trotz des fehlenden Hintergrunds in der Forschung ist die Integration von Anwendungssystemen in Unternehmensnetzwerken durchaus in der Praxis anzutreffen. Insofern bietet sich eine Mehrfachstudie zur Abbildung des Forschungsgegenstands im Vergleich zu einer Einzelstudie an. Die Auswahl unterschiedlicher Fälle im Rahmen einer Mehrfachstudie verbreitert den untersuchten Ausschnitt des Objektbereichs. Die zur Auswahl der Fälle nötigen Kriterien zielen allerdings – insbesondere aufgrund der beschränkten Stichprobe – nicht auf eine vollständige bzw. repräsentative Abdeckung des Untersuchungsbereichs ab.205 Vielmehr bedarf es der Auswahl von Fällen, die im Vergleich zueinander mög-

201 202 203 204 205

Beispielshalber die Fallstudien von Katzy (2005), S. 48-51; Fleisch (2001), S 141-155. Vgl. etwa Yin (2003), S. 4. Vgl. Schnell et al. (2005), S. 250. Vgl. Roll (2003), S. 315 Vgl. Stake (1995), S. 4-7.

46

Grundlagen und Methodenanforderungen

lichst heterogen ausgestaltet sind, wobei sich die Auswahlkriterien aus dem innerhalb der Grundlagenbearbeitung aufgespannten konzeptionellen Rahmen des Untersuchungsbereichs ableiten. Diese umfassen im Detail: x

Anwendungssystemintegration bei Netzwerken mit unterschiedlicher Steuerungsform sowie unterschiedlicher Stabilität der Konfiguration

x

Integration auf unterschiedlichen Ebenen der Zwei-Ebenen-Architektur von Unternehmensnetzwerken

x

Integration verschiedener Integrationsgegenstände und damit unterschiedlicher Architekturen integrierter Anwendungssysteme

Vor diesem Hintergrund der Auswahlkriterien wurden im Zeitraum von November 2004 bis Januar 2006 vier Fallstudien zur Integration von Anwendungssystemen in Unternehmensnetzwerken ausgewählt. Abb. 2.2.1/1 fasst die Ausgangssituation und

Fallstudie

BIEGE 21 AG

Vertriebsnetzwerk

KFS

VisQuaNet

Ausgangslage

isolierte / unstrukturierte Datenbestände

verzögerte Vertragsabwicklung durch Medienbrüche

ineffizientes Kooperationsmanagement durch heterogene IuKLandschaft

mangelnde IT-Unterstützung für das Auftragsmanagement

Zielsetzung

die jeweilige Zielsetzung der im Folgenden vorgestellten Fallstudien in einem Überblick zusammen.

Daten-Sharing für ein vereinheitlichtes Datenmanagement

ApplikationsKommunikation für eine erhöhte Prozessautomatisierung

ApplikationsSharing für optimierte Koordinationsprozesse

ApplikationsSharing für das Management der Auftragsvergabe

Abb. 2.2.1/1: Ausgangslagen und Zielsetzungen innerhalb der Fallstudien

Nach der Vorstellung des Analyse-Rasters für die Methoden aus der Praxis erfolgt im Anschluss die Analyse in einem einheitlichen Schema. Zu Beginn steht dabei zunächst die Beschreibung des jeweiligen Netzwerks sowie die Ausgangssituation vor der Integration. Im Hinblick auf eine spätere Gegenüberstellung wird anschließend das jeweilige Vorgehen anhand der Komponenten des Method Engineerings strukturiert.206 Im Raster der Abb. 2.2.1/2 sind die Fragestellungen festgehalten, die sich für die einzelnen Komponenten des Method Engineerings im Hinblick auf Methoden zur Integration von Anwendungssystemen ergeben.207 Das Raster stellt ebenfalls im An206 207

Vgl. Kapitel 2.3. Vgl. Legner (1999), S. 34.

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

47

schluss an die Methodenanalyse den Rahmen für die Gegenüberstellung der Fallbeispiele dar. Komponente

Merkmal

Fragestellung

Gestaltungsfelder

Welche Gestaltungsfelder behandelt die Methode?

Allgemeine Aktivitäten

Wie ist das allgemeine Vorgehen der Methode?

Dokumentation des Integrationsvorgehens

Welche Dokumente werden bei der Integration erstellt?

Techniken

Detailliertes Integrationsvorgehen

Welche detaillierten Vorgehenshinweise sind enthalten?

Rollen

Rollen bei Integrationsprojekten

Wie ist die organisatorische Ausgestaltung der Integration?

Metamodell

Aktivitäten und Ergebnisse

Abb. 2.2.1/2: Raster zur Methodenbeschreibung

2.2.2 Fallstudienanalyse208 2.2.2.1

Daten-Sharing bei Biege 21

Hintergrund und Ausgangslage Die Biege 21 Management Marketing Consulting AG ist ein in Leonberg ansässiges Unternehmensnetzwerk, das sich primär auf die Geschäftsbereiche „Producing“ von Erlebniswelten sowie die Beratung mit dem Fokus auf das Management von Unternehmensnetzwerken konzentriert. Die Wurzeln der Biege 21 liegen in der „Bietergemeinschaft des Deutschen Handwerks“, die sich aus 14 Handwerksunternehmen unterschiedlicher Branchen und Größen zusammensetzte, mit dem ehrgeizigen Ziel, als flexibles Netzwerk im Gegensatz zu einem „klassischen“ Unternehmen die vollständige Realisierung und den Betrieb des Themenparks der Weltausstellung EXPO 2000 in Hannover zu bewältigen. Die erfolgreiche Umsetzung dieses Projekts führte zu zahllosen Nachfolgeprojekten auf nationaler und internationaler Ebene. Infolgedessen wuchs aus der ursprünglich losen Bietergemeinschaft bis heute ein umfassendes Unternehmensnetzwerk in Form der Biege 21 AG, deren Aktionäre im Wesentlichen durch die Netzwerkpartner gestellt werden. Eine zentrale Rolle im Netzwerk nimmt der Vorstand bzw. das Management der Biege ein. Dieser führt das

208

Vgl. im Folgenden Stadlbauer/Hess (2006).

48

Grundlagen und Methodenanforderungen

Netzwerk tendenziell fokal und tritt typischerweise als Generalunternehmer auf. Je nach Auftrag sind die Netzwerkpartner meist unterschiedliche konfiguriert. Aufgrund der langjährigen Erfahrungen der eigenen Netzwerkarbeit bietet die heutige Biege neben dem Producing zusätzlich das gesammelte Wissen zum Netzwerkmanagement als Beratungsleistung für Unternehmen und Wirtschaftsförderungen an. Im November 2005 schloss sie beispielsweise ein 24 Monate andauerndes, EUgefördertes Projekt zur Bildung und Festigung von Unternehmensnetzwerken im thüringischen Gera erfolgreich ab. Im Rahmen der Projekt- und Akquisitionstätigkeiten sammelte die Biege im Laufe der Zeit eine Vielzahl von Kontaktdaten von Kunden, Projektpartnern etc. Zu deren Verwaltung war im eingesetzten Intranettool des Anbieters Intrexx ein Modul zum zentralen Management dieser Daten enthalten. Diese Lösung war jedoch mit erheblichen Mängeln behaftet. Zum einen fehlte die Möglichkeit, Daten komfortabel in Intrexx zu integrieren. Eine Schnittstelle etwa zu Microsoft Outlook, mit dem die Netzwerkpartner typischerweise ihre Kontakte verwalteten, oder zu Excel bzw. Access war nicht im Einsatz.209 Darüber hinaus war die automatische Zuordnung von Kontakten zu Projekten210 ebenso wie ein Austausch zu den Anwendungssystemen der Netzwerkpartner aufgrund fehlender Schnittstellen nicht oder nur mit erheblichem Aufwand möglich. Nicht zuletzt führte die unkomfortable Bedienung von Intrexx dazu, dass ein Großteil der bestehenden Kontaktdaten lediglich dezentral und unstrukturiert auf die Anwendungssysteme der Netzwerkpartner verteilt war. Eine integrierte Nutzung war ebenso wenig möglich wie der Überblick über den vorhandenen Datenbestand. Ein vereinzelter Austausch der Daten erfolgte meist per E-Mail bzw. telefonisch. Im Rahmen der Projektarbeit stellte dieses Vorgehen eine weitgehend gangbare Lösung dar. Meist wurden nur einzelne Kontakte von anderen Partnern benötigt, so dass ein zentraler Zugriff sowie der Bedarf einer Kopplung nicht angedacht wurden. Die Vorbereitung eines groß angelegten Akquisitionsprojekts der Biege änderte allerdings das Bild. Zunächst wurde erkannt, dass es keinen zentralen Überblick über potenzielle Kunden sowie weitere Kontakte der Biege gab. Die unkomfortable Verwaltung in Intrexx sowie die mangelhaften Schnittstellen zu Ursprungs- und Zielsystemen der Daten ließen darüber hinaus eine weitere Verwendung des bisherigen Tools sinnlos erscheinen. Vielmehr wurde eine Lösung gesucht, die unkompliziert den Import und damit die Kopplung aus den bisherigen Systemen, die Verwaltung

209 210

Ein Teil der Kontaktdaten war ursprünglich in verschiedenen Excel-Listen gesammelt. Das von Intrexx angebotene Projektmanagementmodul mit projektspezifischen Kontaktdaten ließ sich nicht mit den zentralen Kontaktdaten innerhalb von Intrexx verknüpfen, so dass Kontakte eines Projekts, auf die z. B. auch Kunden Zugriff haben sollten, ein weiteres Mal manuell eingegeben werden mussten.

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

49

innerhalb des Systems sowie die möglichst nahtlose spätere Nutzung der Daten in den Anwendungssystemen der Partner ermöglichte.211 Realisiert wurden diese Anforderungen durch eine Integrationsarchitektur, die sich mehrheitlich dem Daten-Sharing zuordnen lässt.212 Ein wesentliches Merkmal dieser Lösung ist entsprechend die zentrale Speicherung der ehemals unsystematisch abgelegten Kontaktdaten in einer einzelnen Datenbank mit Internetschnittstelle. Über die Schnittstelle und enthaltene Import- und Exportfunktionen, die gewünschte Datensätze in standardisierter Form ein- und ausgeben können, lassen sich die Daten von und in den Anwendungssystemen der Netzwerkpartner gemeinschaftlich nutzen. Über die Internetschnittstelle ist ebenfalls eine direkte Eingabe und Verwaltung der Daten innerhalb der zentralen Datenbank möglich.

Metamodell An eine Integrationslösung werden im Fall der Biege-Integration die Anwendungssysteme von Netzwerkpartnern zur Bearbeitung einer Aufgabe gekoppelt. Ausgangspunkt des Metamodells ist das Unternehmensnetzwerk, bei dem im Rahmen der Aufgabenbearbeitung Partnerunternehmen in unterschiedlicher Konfiguration beteiligt sind. Im Rahmen der Netzwerkarbeit ist das Unternehmensnetzwerk mit der Umsetzung einer Aufgabe befasst. Die Umsetzung erfolgt durch die Partnerunternehmen, die im Rahmen der Aufgabenbearbeitung von Anwendungssystemen unterstützt werden. Anhand der vom Netzwerk durchzuführenden Aufgabe wird die Integrationslösung (in Form des Daten-Sharings) ermittelt. Mit der Integrationslösung sind die zur Aufgabenunterstützung eingesetzten Anwendungssysteme verknüpft. Schließlich sind in der Integrationslösung die von den Anwendungssystemen benötigten Daten enthalten. In Abb. 2.2.2.1/1 ist das Metamodell des BiegeIntegrationsvorgehens grafisch dargestellt.

211

212

Aufgrund der schlechten Erfahrungen mit Intrexx und den geplanten Mailingaktionen im Rahmen des Akquisitionsprojekts kam insbesondere der späteren unkomplizierten Datennutzung innerhalb der Partnersysteme (etwa zur Erstellung von Serienbriefen) erhöhte Aufmerksamkeit zu. Vgl. Kapitel 2.1.2.3.

50

Grundlagen und Methodenanforderungen

nimmt wahr

bildet

führt aus

verwendet

Anwendungssystem

ist verknüpft mit

Integrationslösung enthält

Partner

bestimmt Aufgabe unterstützt

Netzwerk

benötigt Daten

Abb. 2.2.2.1/1: Metamodell der Biege-Integration

Vorgehens- und Ergebnismodell Das Biege-Integrationsvorgehen ist in vier Phasen mit jeweils drei Schritten unterteilt. Die Phasen umfassen die (1) Identifizierung eines Integrationsbereichs, die (2) Eingrenzung von Integrationslösungen, die (3) Konzeption der Integrationslösung sowie deren (4) Realisierung. Identifizierung Ausgangspunkt des Vorgehensmodells ist in der ersten Phase die allgemeine Planung des anstehenden Projekts. Im Rahmen der dabei vorgenommenen Ablaufplanung wurden die Möglichkeiten der Projektunterstützung durch die bestehenden Anwendungssysteme überprüft. Aus dieser Überprüfung kristallisierte sich der bestehende Integrationsbereich heraus, der in einem zweiten Schritt zunächst abgegrenzt wurde. Zum Abschluss der Phase wurde schließlich eine erste Ermittlung der benötigten Funktionen eines integrierten Ansatzes vorgenommen. Eingrenzung Auf Basis des zum Abschluss der vorherigen Phase ermittelten Funktionsumsatzes stand zu Beginn der zweiten Phase zunächst die Sondierung möglicher Lösungsvarianten im Vordergrund. Geklärt wurde dabei erst einmal, welche grundsätzliche Architektur zur Lösung des Integrationsproblems infrage käme.213 In einem zweiten Schritt wurde in Anschluss daran anhand eines einfach strukturierten Kriterienkatalo213

Im konkreten Fall ging es insbesondere um die Frage, ob eine zentrale Architektur mit Zugriff über das Internet gewählt werden sollte (im Sinne eines Daten- bzw. Applikations-Sharings), oder ob eine dezentrale Variante gemäß der Applikations-Kommunikation zu bevorzugen wäre. Dabei stellte sich heraus, dass sich insbesondere das Daten- und Applikations-Sharing eigne. Die Applikations-Kommunikation hingegen schied aufgrund bestehender Sicherheitsrichtlinien sowie der stark dezentralen Arbeitsweise der Mitarbeiter der Netzwerkpartner mit häufigen Phasen ohne Internetanbindung aus.

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

51

ges die Eingrenzung potenzieller Lösungsmöglichkeiten vorgenommen. Dabei stand insbesondere die Frage der Wirtschaftlichkeit unterschiedlicher Systeme im Vordergrund. Die erhaltenen Lösungsvarianten wurden in einem weiteren Schritt im Hinblick auf ihren vollständigen Funktionen genau analysiert. Anhand dieser Analyse ließ sich der bisher lediglich grob festgehaltene Funktionsumfang der zu wählenden Integrationslösung genauer spezifizieren. Konzeption Die dritte Phase umfasste primär die Konzeption der Integrationslösung. Dazu erfolgte in einem ersten Schritt die Vorauswahl einer einzigen Lösungsvariante, die daraufhin durch einen Pilottest im Detail auf ihre Eignung untersucht wurde.214 Anhand des erfolgreichen Pilottests wurde zum Ende der dritten Phase der finale Funktionsumfang der Integrationslösung festgelegt und in Form eines vereinfachten Pflichtenhefts, welches die nötigen Erweiterungen und Anpassungen enthielt, festgehalten. Realisierung Aufgrund der positiven Reaktion des Anbieters der integrierten Lösung auf die durchzuführenden Änderungen die im Pflichtenheft erfasst waren, erfolgte zu Beginn der vierten Phase schließlich die definitive Festlegung auf ein Produkt. Diese wurde im Anschluss daran in die Systemlandschaft der Biege implementiert, um die noch nicht enthaltenen Funktionen erweitert sowie an die Besonderheiten der Biege angepasst (Customizing). Die Realisierung stellt den Endpunkt des Integrationsvorgehens der Biege dar.

Techniken Das Integrationsvorgehen der Biege wurde lediglich ansatzweise durch Techniken unterstützt. Im Rahmen der Evaluation möglicher Integrationslösungen innerhalb der zweiten Phase war das gewählte Vorgehen an den klassischen Softwareauswahlprozess angelehnt. Zahlreiche Ansätze dazu lassen sich in der Literatur finden. Im Kern sind diese, wie auch beim Vorgehen der Biege, auf eine einfache, kriteriengestützte Auswahl zurückführen.215 Dafür gilt es zunächst, passende Kriterien für das entsprechende Einsatzszenario zu ermitteln und zu gewichten. Im Anschluss sind die infrage kommenden Softwareprodukte anhand dieser Kriterien zu bewerten. Im Rahmen des Biege-Integrationsvorgehens wurden dementsprechend zunächst allgemeine Krite-

214

215

Die gewählte Variante gehörte ursprünglich nicht zu den eingegrenzten Lösungsvarianten der vorherigen Phase. Durch die dort allerdings erstmalig vorgenommene detaillierte Festlegung des benötigten Funktionsumfangs bot sich eine bisher nicht beachtete Variante an. Vgl. etwa Dangelmaier et al. (2002), S. 68-71.

52

Grundlagen und Methodenanforderungen

rienklassen gebildet die (1) Funktionsumfang, Bedienungsfreundlichkeit, Konvektivität sowie Einbindung in die bestehende Systemlandschaft, (2) Einführungs- und Betriebskosten sowie (3) Service, Vertrauenswürdigkeit und Referenzen des Anbieters umfassten. Anhand dieser Kriterien wurden die identifizierten Lösungen beurteilt. Durch das gewählte Vorgehen ließen sich drei Lösungsmöglichkeiten zur genaueren Begutachtung extrahieren. Darüber hinaus wurde zur Ermittlung des Funktionsumfangs bzw. der zu integrierenden Anwendungssysteme ansatzweise auf das Analyse-Synthese-Schema zurückgegriffen. Das Analyse-Synthese-Schema ist eine aus der Organisationstheorie stammende Technik, die durch die Dekomposition der Unternehmensaufgabe in ihre elementaren Aufgabenbestandteile sowie deren anschließende Synthese und damit deren Zusammenfassung zu sinnvollen organisatorischen Einheiten die Komplexität von Aufgaben durch die Bildung von einzelnen Aufgabenpaketen vermindert.216 Im Rahmen der Biege-Integration wurden die durch die Dekomposition erhaltenen elementaren Bestandteile des Projekts auf ihre mögliche Unterstützung durch die ausgewählte Integrationslösung untersucht. Anhand dieses Vorgehens konnten der sinnvolle Einsatz, betroffene Schnittstellen sowie die benötigten Anpassungen und Erweiterungen der anvisierten Integrationslösung ermittelt werden. Aus dem durch das Analyse-Synthese-Schema ermittelten Funktionsumfang wurde ein stark vereinfachtes Pflichtenheft erstellt. Das Pflichtenheft ist eine verbreitete Technik aus der Softwareentwicklung. Das Ziel eines Pflichtenhefts ist die detaillierte Beschreibung einer zu erfüllende Leistung, wozu es in verschiedene Gliederungsabschnitte strukturiert ist (vgl. Abb. 2.2.2.1/2). •

Zielbestimmung

•

Qualitätsanforderungen

•

Produkteinsatz

•

Benutzungsoberfläche

•

Produktübersicht

•

Nichtfunktionale Anforderungen

•

Produktfunktionen

•

Technische Produktumgebung

•

Produktdaten

•

•

Produktleistungen

Anforderungen an die Entwicklungsumgebung

•

Gliederung in Teilprodukte

Abb. 2.2.2.1/2: Typische Gliederungspunkte eines Pflichtenhefts217

Wie beschrieben wurde im Rahmen des Biege-Integrationsvorgehen kein vollständiges Pflichtenheft entwickelt. Beschränkt war es auf eine Beschreibung von nötigen

216 217

Vgl. Picot et al. (2005), S. 228-230. Zusammengefasst aus den Inhalten eines Pflichtenhefts nach Balzert (vgl. Balzert (2000), S. 111121).

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

53

Produktfunktionen, die Ermittlung von Anforderungen und Zugriffsrechten im Rahmen der Benutzeroberfläche sowie Beschreibungen der technischen Produktumgebungen durch die enthaltenen Anforderungen an die Produktschnittstelle.

Rollenmodell Im Rahmen des Integrationsvorgehens der Biege sind die Rollen „Projektverantwortliche“, „Projektmanager“ sowie „Anwender“ von hervorzuhebender Bedeutung. Die Aufgaben der Projektverantwortlichen – besetzt durch Vertreter des TopManagements des Netzwerks – lagen in der strategischen Ausrichtung des Projekts und – wie der Name bereits sagt – in der Projektverantwortung. Zentrale Bestandteile dieser Aufgabe liegen in der Projektinitiierung, der Festlegung des Funktionsumfangs der Integrationslösung sowie in der finalen Bestimmung der später genutzten Lösung. Die Aufgaben des Projektmanagers fokussierten im Vergleich dazu primär die operativen Tätigkeiten der Projektdurchführung. Im Kern umfassen sie die Vorauswahl möglicher Lösungsvarianten durch deren Evaluation, sowie die spätere Steuerung und Kontrolle der Implementierung. Besetzt wurde die Rolle des Projektmanager mit einem IT-beauftragten Mitarbeiter eines in das Projekt involvierten Netzwerkpartners. Schließlich kam beim Integrationsvorgehen als dritte Rolle den Anwendern der Biege eine unterstützende Aufgabe zur Ermittlung des benötigten Funktionsumfangs der integrierten Lösung zu. Besetzt wurde diese Rolle durch Mitarbeiter eines Netzwerkspartners, die für die spätere Nutzung der Lösung vorgesehen waren. 2.2.2.2

Applikations-Kommunikation in einem Vertriebsnetzwerk

Hintergrund und Ausgangslage Die zweite Fallstudie beschreibt das Integrationsvorgehen eines deutschlandweit agierenden Vertriebsnetzwerks. Aufgebaut ist das Netzwerk in Form eines Fertigungsunternehmens, dessen Produkte über rund 800 Vertriebsgesellschaften abgesetzt werden.218 Werden die Beziehungen zwischen dem Fertigungsunternehmen und den Vertriebsgesellschaften betrachtet, so finden sich netzwerkartige Charakteristika. Zunächst zeichnen sich die Vertriebsgesellschaften durch ihre rechtliche und – zumindest vor dem Kooperationsbeginn mit dem Fertigungsunternehmen – wirtschaftliche Selbständigkeit aus. Mit dem Vertrieb der Produkte wird zusätzlich ein leistungswirtschaftliches Sachziel verfolgt, wobei die Kooperationspartner dies mittels Funktionsabstimmung im Vergleich zur Funktionszusammenlegung realisieren. Das

218

Vgl. im Folgenden auch Kudrna (2005), S. 37-51.

54

Grundlagen und Methodenanforderungen

Verhältnis zwischen dem Fertigungsunternehmen und den Vertriebsgesellschaften hat schließlich einen unbefristeten und auf Verträgen zwischen den Fertigungsunternehmen und den Vertriebsgesellschaften beruhenden Charakter. Insofern lassen sich sämtliche Charakteristika eines Unternehmensnetzwerks, wie im zweiten Kaptitel vorgestellt, innerhalb des Vertriebsnetzwerks finden.219 Die Fertigungsgesellschaft nimmt dabei eine zentrale Rolle ein und stellt demzufolge den fokalen Partner des Netzwerks dar. Zusätzlich kennzeichnet sich das Netzwerk durch seine stabile Konfiguration. Im Rahmen des Vertriebsprozesses sind die Vertriebsgesellschaften typischerweise mit dem Abschluss eines Vertrages zwischen dem Fertigungsunternehmen und dem jeweiligen Kunden betraut. Kennzeichen des Prozesses ist die Erstellung des Vertrages über ein vom Fertigungsunternehmen bereitgestelltes, webbasiertes Anwendungssystem. Der erstellte Vertrag wird im Anschluss von den Vertriebsgesellschaften ausgedruckt. Bevor er zur Unterschrift an den Kunden gegeben wird, nehmen die Vertriebsgesellschaften jedoch häufig manuelle Änderungen direkt auf dem Vertrag vor. Der unterschriebene Vertrag wird anschließend per Post an das Fertigungsunternehmen geschickt. Die manuell vorgenommenen Änderungen durch die Vertriebsgesellschaften werden dort in die Anwendungssysteme des Fertigungsunternehmens übernommen und der Vertrag sowohl elektronisch als auch physisch archiviert. Aufgrund der Verwendung des Vertrages in Papierform und den damit verbundenen manuellen Schritten, gestaltete sich der Vertragsprozess zeitaufwendig und wenig effizient. Durch den Zwang einer manuellen Unterschrift des Vertrages wurde jedoch keine Möglichkeit der Prozessverbesserung gesehen. Aufgrund der jüngsten Entwicklungen der biometrischen Technologien änderte sich diese Einschätzung allerdings. So kann durch die Digitalisierung der Unterschrift des Kunden und ihre Verknüpfung mit einem digitalen Vertrag größtenteils auf den Einsatz von Papier und damit auf einige der manuellen Bearbeitungsschritte verzichtet werden. Nötig ist dazu lediglich die Digitalisierung der Kundenunterschrift – etwa durch den Einsatz eines ePads – und die Verwendung eines einheitlichen Standards, der die Datenübermittlung zwischen den beteiligten Anwendungssystemen des Netzwerks ermöglicht. Entsprechend ist die gewählte Integrationsarchitektur mehrheitlich der ApplikationsKommunikation zuzuordnen, da außer dem ePad zur Digitalisierung der Unterschrift weitgehend auf die bestehende Anwendungssystemlandschaft zurückgegriffen werden konnte, wobei zur Eliminierung der bestehenden Medienbrüche die Kommunikation zwischen den Anwendungssystemen unter Verwendung eines einheitlichen Standards ermöglicht wurde. Infolgedessen wurde mehrheitlich auf die Integrations-

219

Vgl. Kapitel 2.1.1.2.

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

55

architektur der Applikations-Kommunikation zurückgegriffen, die eine durchgängige Integration aller am Prozess beteiligten Anwendungssysteme ermöglichen sollte.220

Metamodell Die Digitalisierung und Standardisierung von zuvor nicht in digitaler Form vorliegender Daten ermöglicht im Rahmen des Vertriebsnetzwerk-Fallbeispiels die Integration durch Applikations-Kommunikation. Die nicht fokalen Netzwerkpartner setzen dazu Digitalisierungstechnologien ein.221 Diese Technologien ermöglichen die Digitalisierung der ursprünglich nicht in digitaler Form vorliegenden Daten und die Umwandlung in ein standardisiertes Datenformat. Die von den Netzwerkpartnern zur Unterstützung des Prozesses eingesetzten Anwendungssysteme können die standardisierten Datenformate über vorhandene Schnittstellen übertragen, verarbeiten und speichern. In Abb. 2.2.2.2/1 ist das Metamodell der Integration des Vertriebsnetzwerks grafisch dargestellt. bearbeitet

unterstützt

Prozess

nicht fokaler Partner

nutzt

fokaler Partner

nutzt

ist verbunden mit Anwendungshat system

standardisierte Schnittstelle überträgt

bearbeitet

verarbeitet / stellt bereit

setzt ein

Digitalisierungstechnologie

erzeugt

standardisierte Daten

Abb. 2.2.2.2/1: Metamodell der Integration des Vertriebsnetzwerks

Aktivitäten- und Ergebnismodell Das Vorgehensmodell der Integration des Vertriebsnetzwerks ist grob in drei Phasen gegliedert, die über insgesamt sieben Schritte verteilen. Die drei Phasen umfassen (1) Vorstudie, (2) Prozessanalyse und Konzeption sowie (3) Wirtschaftlichkeitsanalyse und werden im Folgenden skizziert. 220 221

Vgl. Kapitel 2.1.2.3. Digitalisierungstechnologien sollen im Folgenden zusammenfassend für die biometrischen Verfahren zur Digitalisierung der Unterschrift stehen.

56

Grundlagen und Methodenanforderungen

Innovationsvorschlag Der Innovationsvorschlag beinhaltete eine erste Evaluierung des Einsatzes von biometrischen Verfahren, um den Prozess der Vertragsabwicklung zwischen Vertriebsgesellschaft und dem Fertigungsunternehmen vollständig in digitaler Form durchzuführen. Ausgangspunkt war die Ermittlung einer Übersicht über bestehende biometrische Verfahren. Daran anschließend wurden mögliche Anbieter der dafür nötigen Technologien ermittelt und einer davon schließlich ausgewählt. In Zusammenarbeit mit dem Anbieter erfolgte im Anschluss die erste Konzeption eines möglichen Anwendungsszenarios für den konkreten Vertragsabwicklungsprozess. Mit Durchführung einer Vorteilhaftigkeitsanalyse schloss die Vorstudie schließlich ab. Prozessanalyse und Konzeption Die zweite Phase zielte auf die detaillierte Ermittlung der betroffenen Prozesse ab. Mittels Experteninterviews wurden zu Beginn der zweiten Phase der bestehende Prozess sowie die dazu eingesetzten Anwendungssysteme erfasst. Der ermittelte Prozess wurde dazu mittels ereignisgesteuerter Prozessketten (EPKs)222 visualisiert. Im Anschluss daran wurde der dokumentierte Prozess unter Zuhilfenahme der Experteninterviews im Hinblick auf bestehende Schwachstellen untersucht. Am Ende der zweiten Phase wurde der Soll-Prozess – ebenfalls visualisiert durch EPKs – konzipiert sowie die dafür nötigen Veränderungen der bestehenden Systemlandschaft ermittelt. Wirtschaftlichkeitsanalyse In Form einer detaillierten Kosten-/Nutzenanalyse wurde in der letzten Phase schließlich die Wirtschaftlichkeit des integrierten Prozesses sowie die Amortisationszeit der zu tätigen Investitionen ermittelt. Aufgrund ausstehender netzwerkpolitischer Entscheidungen wurde dem erfolgreichen Abschluss des bisherigen Projektvorgehens zum Trotz die Integration erst einmal nicht weiter geführt.

Techniken Das Integrationsvorgehen des Vertriebsnetzwerks wurde insbesondere in der zweiten und dritten Phase durch Techniken unterstützt. In der zweiten Phase wurde eine Prozessanalyse für die Ermittlung des Ist-Prozesses vorgenommen. Als Technik kamen hierbei zum einen offene Experteninterviews zum Einsatz. Dabei wurden die am untersuchten Prozess beteiligten Personen aufseiten des Vertriebsnetzwerks anhand eines Interviewleitfadens zu den einzelnen Schritten des Prozesses und zu bestehenden Schwachstellen befragt.

222

Vgl. Scheer (2002), S. 10-31.

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

57

Ebenfalls in dieser Phase wurden Vorgangskettendiagramme erstellt. Unterstützt durch die Software ARIS Toolset (ATS) wurde der Ist- sowie der Soll-Prozess in Form von ereignisgesteuerten Prozessketten modelliert und visualisiert. Schließlich wurde in der zweiten Phase eine Schwachstellenanalyse vorgenommen.223 Dabei werden die ermittelten Prozessschritte im Detail unter anderem im Hinblick auf Medienbrüche, redundante Datenhaltung / Bearbeitungsschritte und fehlende Funktionalitäten innerhalb der eingesetzten Anwendungssysteme untersucht. Innerhalb der dritten Phase wurden des Weiteren Techniken zur Ermittlung der Wirtschaftlichkeit der zu tätigenden Investitionen eingesetzt. Eine durchgeführte Kosten- / Nutzenanalyse ließ die Investitionsvorteilhaftigkeit abschätzen. Dazu wurden die zu tätigenden Investitionen in Hard- und Software und den geschätzten Betriebskosten ermittelt und den erwarteten Einsparungen aus der Prozessoptimierung gegenübergestellt. Ebenfalls ermittelt wurde im Rahmen der Wirtschaftlichkeitsbetrachtung die Amortisationsdauer des Integrationsprojekts anhand der Berechnung des Return on Investment (ROI).224

Rollenmodel Das Rollenmodell des Integrationsvorgehens des Vertriebsnetzwerks umfasst die Rollen Projektleiter, Projektmitarbeiter, IT-Experte, Prozessexperte sowie externe Technologieexperten, die im Folgenden skizziert werden. Die Rolle des Projektleiters ist durch einen leitenden IT-Manager des fokalen Partners besetzt. Der Projektleiter hat bedeutenden Anteil an der Erstellung des Innovationsvorschlages und ist für die Projektsteuerung verantwortlich. Der Projektmitarbeiter als zweite Rolle wird durch einen Mitarbeiter des fokalen Partners besetzt. Zentrale Aufgaben des Projektmitarbeiters liegen in der detaillierten Erfassung des Ist- und Sollprozesses sowie der Schwachstellenanalyse, die beide als Grundlage in die ebenfalls von ihm durchgeführte Wirtschaftlichkeitsanalyse fließen. Unterstützt werden Projektleiter und -mitarbeiter im Rahmen des Projekts durch ITExperten, Prozessexperten und externe Technologieexperten. Erstere sind durch ITBeauftragte des fokalen Partners besetzt. Mit ihrem Expertenwissen unterstützen sie die Ermittlung der im Rahmen des Ist-Prozesses betroffenen Systeme sowie die Konzeption der Systemlandschaft des Soll-Prozesses. Die Prozessexperten tragen mit ihrem Expertenwissen über die einzelnen Prozessschritte sowie die enthaltenen Schwachstellen des Weiteren zur Prozess- und Schwachstellenanalyse bei. Die externen Technologieexperten sind schließlich durch Mitarbeiter des Anbieters der ge-

223 224

Vgl. Zum Einsatz einer Schwachstellenanalyse im Detail etwa Becker et al. (2005), S. 86-96. Zur Ermittlung des ROI vgl. etwa Reichmann (2001), S. 94.

58

Grundlagen und Methodenanforderungen

wählten Lösungsvariante besetzt. Durch ihr Expertenwissen zur einzusetzenden Technologie des Soll-Prozesses unterstützen sie die Konzeption des Lösungsansatzes. 2.2.2.3

Eigenentwickeltes Applikations-Sharing bei KFS

Hintergrund und Ausgangslage Der Kooperationsverbund Fertigungstechnik Südthüringen (KFS) ist ein aus zehn Partnerunternehmen bestehendes Unternehmensnetzwerk mit Fokus auf die metallbearbeitende Industrie. Entstanden aus einer losen Zusammenarbeit von ursprünglich vier metallbearbeitenden Unternehmen gehen die Wurzeln des Netzwerks rund sechs Jahre etwa in das Jahr 2000 zurück. Diese ersten Kooperationserfahrungen stellten im Jahre 2003 den Ausgangspunkt für weiterführende Überlegungen einer Netzwerkbildung dar. Gefördert unter anderem durch Mittel des Bundesministeriums für Wirtschaft und Technologie sowie unter der fachlichen Betreuung durch den „DLR Projektträger Neue Medien in der Wirtschaft“ hat sich bis heute ein zehn Partnerunternehmen umfassendes Netzwerk geformt, dessen Weiterentwicklung durch die Aufnahme von weiteren Netzwerkpartnern aktiv angestrebt wird. Bei einer Auftragsbearbeitung durch das KFS nimmt ein Netzwerkpartner typischerweise eine zentrale Rolle ein. Dieser zentrale Partner stellt die Schnittstelle zum Kunden dar und ist für die Auftragssteuerung innerhalb des Netzwerks verantwortlich. Einem bestimmten Partner des Netzwerks kommt aufgrund der Vielzahl von Aufträgen, die über ihn an das Netzwerk herangetragen werden, eine dominierende Rolle innerhalb des KFS zu. Daraus lassen sich Kennzeichen einer fokalen Steuerungsform ableiten. An der konkreten Auftragsrealisierung sind darüber hinaus meist unterschiedliche Partner beteiligt, so dass die Konfiguration des Netzwerks bei der Auftragsbearbeitung weitgehend instabil ist. 225 Das Netzwerk verfolgt zwei zentrale Ziele. Zunächst zielen die Partner auf eine Erweiterung ihres Leistungsspektrums durch das Netzwerk, indem auf vielfältige Kompetenzen der Partnerunternehmen zur Auftragsrealisierung zurückgegriffen wird. Damit sollen Aufträge akquiriert werden, die ein einzelnes Unternehmen aufgrund fehlender Kompetenzen bzw. maschineller Ausstattung nicht realisieren könnte. Darüber hinaus zielt der KFS auf den Ausgleich der vorhandenen Kapazitäten ab, womit sich innerhalb des Netzwerks Aufträge realisieren lassen, zu dessen Durchführung

225

Zur Steuerungsform und Konfiguration der Auftragsbearbeitung von Netzwerken vgl. Kapitel 2.1.1.3.

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

59

ein einzelnes Partnerunternehmen aufgrund mangelnder Kapazitäten nicht in der Lage wäre. Die beschriebene Konfiguration des Netzwerks bei der Auftragsbearbeitung sowie die Umsetzung der angestrebten Netzwerkziele führen zu einem bedeutenden Koordinationsbedarf innerhalb des KFS. Bei der Intensivierung der Zusammenarbeit zeigten sich allerdings erhebliche Schwachstellen bei den etablierten Koordinationsprozessen. Bei der Begutachtung dieser Schwachstellen ließ sich ein Teil der bestehenden Probleme auf die eingesetzten IKT des Netzwerks zurückführen. Kennzeichnen ließen sich diese durch die heterogenen Anwendungen, die von den Netzwerkpartnern verwendet wurden. Eine einheitliche bzw. zueinander kompatible IT-Basis war im Netzwerk dementsprechend nicht anzutreffen. Infolgedessen erfolgte die Übertragung nötiger Informationen zur Abstimmung zwischen den Netzwerkpartnern primär per Fax oder Post, so dass die Koordinationsprozesse des Netzwerks durch zeitaufwendige Medienbrüche verbunden mit manuellen Arbeitsschritten geprägt waren. Darüber hinaus brachte die bestehende heterogene Systemlandschaft einen weiteren Nachteil mit sich. Aufgrund der heterogenen IT-Systeme und das Fehlen einer einheitlichen Datenbasis wurden die Daten des Netzwerks lediglich dezentral bei den jeweiligen Netzwerkpartnern gespeichert. Aufgrund des fehlenden Zugriffs auf die Daten bei den Netzwerkpartnern und dem Fehlen einer zentralen Verwaltung war der jederzeit mögliche und damit kurzfristige Datenzugriff sowie eine stete Gewährleistung der Datenaktualität zu keinem Zeitpunkt gegeben. Insofern wurde vom Netzwerk nach einer Lösung gesucht, die zum einen wiederholt anfallende Koordinationsprozesse insbesondere durch die Minimierung der bestehenden Medienbrüche effizienter ausgestalten könnte sowie zusätzlich den jederzeit möglichen Zugriff auf eine aktuelle Datenbasis beinhalten würde. Zur Realisierung dieser Anforderungen wurde auf eine Integrationsarchitektur zurückgegriffen, die sich überwiegend dem Applikations-Sharing zuordnen lässt. 226 Dazu wurde eine Web-Anwendung entwickelt, mittels der – im Sinne einer aufgabenorientierten Funktionsintegration – die wiederholt anfallenden Koordinationsprozesse des Netzwerks weitgehend nahtlos unterstützt werden sollten.227 Ebenfalls sollte sie in Anlehnung an die Architektur des Applikations-Sharings die im Rahmen der Koordinationsprozesse anfallenden Daten zentral und einheitlich speichern.

226 227

Vgl. Kapitel 2.1.2.3. Zur aufgabenorientierten Funktionsintegration vgl. Kapitel 2.1.2.2.

60

Grundlagen und Methodenanforderungen

Metamodell Das Integrationsvorgehen von KFS zielt auf den Erhalt einer an das ApplikationsSharing angelehnten Architektur ab. Infolgedessen stellt das integrierte Anwendungssystem das zentrale Element des Metamodells dar. Bestimmt wird der Funktionsumfang des Systems durch den zu unterstützenden Prozess. Bei der Prozessdurchführung wird die dabei nötige Steuerung primär vom Anwendungssystem übernommen. Ausgelöst wird der Prozess durch die Partnerunternehmen, die Zugriff auf das integrierte Anwendungssystem haben und über dieses Daten eingeben bzw. modifizieren. Zur Modifikation bzw. Eingabe der Daten werden im Anwendungssystem enthaltene Funktionen genutzt. Diese sind derart miteinander verknüpft, dass der im integrierten Anwendungssystem abgebildete Prozess weitgehend durch die enthaltenen Funktionen abgedeckt wird. Die Funktionen benötigen für ihre Durchführung Daten, wobei als Ergebnis einer Funktionsausführung wiederum Daten erhalten bzw. bereits enthaltene Daten modifiziert werden. In Abb. 2.2.2.3/1 ist das Metamodell der KFS-Integration grafisch dargestellt. ist Teil von

hat

Partner

nutz

beinhaltet

beinhaltet

Anwendungssystem

ist verbunden mit

führt aus / löst aus

steuert

Prozess bestimmt

Netzwerk

Funktion

Daten

ist In-/Output

Abb. 2.2.2.3/1: Metamodell der KFS-Integration

Aktivitäten- und Ergebnismodell Das Aktivitätenmodell des KFS-Integrationsvorgehens lässt sich grob in die vier Phasen (1) Abgrenzung, (2) Definition der Lösung, (3) Pilotierung und (4) Einführung gliedern, die im Folgenden nachgezeichnet werden.

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

61

Abgrenzung Ausgangspunkt des Integrationsvorgehens des KFS stellte die Analyse der bestehenden Geschäftsprozesse der Partnerunternehmen dar. Ermittelt wurden sowohl Geschäftsprozesse, die die Kooperation betrafen sowie darüber hinaus auch Prozesse der Partnerunternehmen außerhalb der Kooperationsbeziehung. Im Mittelpunkt der Phase stand daraufhin die Entwicklung von schriftlich fixierten Szenarien der Kooperationsprozesse, die von der angestrebten Lösung unterstützt werden sollten. Anhand der erstellten Szenarien ließ sich schließlich der nötige Funktionsumfang der integrierten Lösung ableiten. Unterstützt wurde KFS dabei von einem beauftragten Softwareentwickler. Definition der Lösung Mittels der ermittelten Szenarien und dem Funktionsumfang wurden in der zweiten Phase mögliche Lösungsvarianten recherchiert und in Bezug auf ihre Eignung untersucht. Geleitet wurde diese Untersuchung vom Anspruch, den festgelegten Funktionsumfang weitgehend zu treffen. Infolgedessen wurde den ebenfalls in dieser Phase durchgeführten Wirtschaftlichkeitsbetrachtungen im Vergleich zum abgedeckten Funktionsumfang eine untergeordnete Rolle zugeschrieben. Mit anderen Worten, es konnte eine Lösung, die den Funktionsumfang exakter abdeckte, bei möglicherweise schlechterem Ergebnis der Wirtschaftlichkeitsbetrachtung insgesamt besser bewertet werden. Ausgehend von den getätigten Recherchen und dem durchgeführten Vergleich wurde schließlich eine Lösungsvariante ausgewählt. Den Abschluss der zweiten Phase bildete die Erstellung eines Pflichtenheftes. Pilotierung Auf Basis des Pflichtenhefts wurde in der dritten Phase zunächst die Entwicklung der Integrationslösung vorgenommen. Diese wurde parallel umfangreichen Tests unterzogenen. In deren Rahmen simulierten vier Partnerunternehmen des Netzwerks (Pilotpartner) die von der Lösung unterstützten Kooperationsprozesse. Die daraus erhaltenen Testergebnisse flossen in Form von Fehlerverbesserungen und Funktionsmodifikationen in die Pilotenentwicklung ein. Einführung In der abschließenden Einführungsphase wurde die entwickelte Software zunächst final implementiert sowie die Schulung der späteren Nutzer durchgeführt. Zusätzlich wurde ein Leitfaden zur Systemnutzung erarbeitet.

62

Grundlagen und Methodenanforderungen

Techniken Im Rahmen des KFS-Integrationsvorgehens wurde ansatzweise auf Techniken zurückgegriffen. Zu nennen ist in der ersten Phase die Geschäftsprozessanalyse der Kooperationsprozesse sowie sonstige Prozesse der Partnerunternehmen. In der zweiten Phase wurde ein Pflichtenheft erstellt. Diese Technik aus der Softwareentwicklung zielt auf eine detaillierte und vollständige Beschreibung einer zu erstellenden Leistung.228 Schließlich wurde in der dritten Phase ein Pilottest durchgeführt. Wie die Erstellung eines Pflichtenhefts ist der Pilottest ebenfalls eine innerhalb der Softwareentwicklung verbreitete Technik. Ein Pilottest zielt unter anderem auf die Prüfung von entscheidenden Systemfunktionen durch die späteren Nutzer.229 Dafür werden die vorgesehenen Anwendungsfälle des Systems in einer Testumgebung simuliert. Damit sollen vor der Implementierung grundsätzliche konzeptionelle Fehler aufgedeckt und korrigiert werden. Typischerweise ist der Funktionsumfang des zu überprüfenden Anwendungssystems noch nicht vollständig realisiert, sondern auf die entscheidenden Funktionen zum Einsatz beschränkt.

Rollenmodell Vier Rollen – im Folgenden skizziert – waren beim KFS-Integrationsvorgehen von besonderer Bedeutung. Die Projektleitung war durch einen externen Berater des Netzwerks besetzt. In das Aufgabengebiet der Projektleitung fiel insbesondere die Projektsteuerung über sämtliche Phasen hinweg. Dazu fungierte die Projektleitung als zentrale Schnittstelle, die über regelmäßige Abstimmungstreffen mit den weiteren Beteiligten umfassend in sämtliche Projektaktivitäten eingebunden war. Die Nutzer als weitere Rolle des KFSIntegrationsvorgehens wurden durch Mitarbeiter (zum Teil leitende) der Netzwerkpartner besetzt. Als Experten für die in der angestrebten Lösung abgebildeten Kooperationsbeziehungen wurden sie zu deren Identifizierung eingesetzt. Als spätere Nutzer des integrierten Systems kam ihnen ebenfalls eine unterstützende Funktion bei der Abgrenzung des Funktionsumfangs sowie als Teilnehmer des Pilottest zu. Einem beauftragten externen Softwareanbieter kam zu Beginn des Projekts die Unterstützung bei der Ermittlung des benötigten Funktionsumfangs der integrierten Lösung zu. Im weiteren Projektverlauf wurde von Softwareentwicklern die Lösung entwickelt sowie daran anschließend die Schulung der Nutzer vorgenommen.

228 229

Vgl. Kapitel 2.2.2.1. Vgl. Janson (1986), S. 210.

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

Als

letzte

Rolle

waren

schließlich

externe

Softwareanbieter

63

am

KFS-

Integrationsvorgehen beteiligt, deren Aufgabe in der Vorstellung unterschiedlicher Lösungsvarianten lag. 2.2.2.4

Standardisiertes Applikations-Sharing bei VisQuaNet

Hintergrund und Ausgangslage VisQuaNet ist ein Unternehmensnetzwerk aus primär auf die technische Bildgewinnung und Verarbeitung spezialisierten Unternehmen aus Thüringen. Fokussiert ist das Netzwerk auf die Entwicklung und Vermarktung von visuellen Qualitätssicherungssystemen mit digitaler Bildverarbeitung und ihren Komponenten. Gefördert durch das Bundesministerium für Wirtschaft und Technologie im Rahmen des Förderprogramms „NEMO Netzwerkmanagement Ost“ formierte sich VisQuaNet im Jahr 2004 unter der Leitung des Mikrotechnik Thüringen e.V. (MTT) in der Rolle als Netzwerkmanager. Von anfänglich acht Netzwerkpartnern hat sich die Anzahl bis ins Jahr 2006 auf vierzehn erhöht, wobei mittlerweile auch überregionale Partner aus entfernten Branchen zum festen Partnerstamm des Netzwerks zählen. Trotz der zentralen Rolle als Netzwerkmanager fungiert der MTT nur als Moderator des Netzwerks. Da auch keiner der Partnerunternehmen eine dominierende Rolle einnimmt, handelt es sich bei VisQuaNet im Kern um ein polyzentrisches Netzwerk. An den zu bearbeitenden Aufträgen sind typischerweise unterschiedliche Netzwerkpartner beteiligt, so dass im Falle von VisQuaNet eine mehrheitlich instabile Netzwerkkonfiguration der Auftragsrealisierung vorliegt.230 Bei der von VisQuaNet angestrebten übergreifenden Zusammenarbeit der Partnerunternehmen innerhalb des Netzwerks zeichnete sich eine Besonderheit ab. Bei der Netzwerkbildung wurden zu großen Teilen Partnerunternehmen zusammengeführt, die zuvor in keiner Kooperationsbeziehung zueinander standen. Aus diesem Grund gab es zu Beginn der Netzwerkarbeit nur begrenzt die Möglichkeit, auf etablierte unternehmensübergreifende Prozesse und Abstimmungsmechanismen zurückzugreifen. Zusätzlich erschwert wurde die Zusammenarbeit durch das Fehlen einer einheitlichen IT-Infrastruktur. Eine effiziente Informationsübermittlung innerhalb des Netzwerks war daher nicht gegeben. Anhand des beispielhaft vorgestellten Auftragsvergabeprozesses lassen sich die vorliegenden Problemfelder anschaulich nachzeichnen. Ein an das Netzwerkmanagement übermittelter potenzieller Netzwerkauftrag eines Kunden wurde nicht unmittel-

230

Zur Steuerungsform und Konfiguration der Auftragsbearbeitung von Netzwerken vgl. Kapitel 2.1.1.3.

64

Grundlagen und Methodenanforderungen

bar mit Kenntnisnahme an die Netzwerkpartner übermittelt. Entsprechende Mechanismen dazu waren nicht vorhanden. Vielmehr wurden die Partner erst mit erheblicher zeitlicher Verzögerung (bei einem der regelmäßig stattfindenden Netzwerktreffen) über den potenziellen Auftrag informiert. Ob dieser zum Zeitpunkt der Übermittlung noch Bestand hatte, konnte aufgrund der Verzögerung allerdings nicht gewährleistet werden. Neben den fehlenden Mechanismen zur kurzfristigen Kommunikation fehlte es ebenfalls an Verfahren für eine wirtschaftliche Auftragsvergabe innerhalb des Netzwerks. So wurde der Auftrag nicht an den Netzwerkpartner mit dem wirtschaftlichsten Angebot zur Auftragsrealisierung vergeben, sondern ein Netzwerkpartner per Losentscheid zufällig ausgewählt. Mechanismen zur Ermittlung des für den Auftrag am besten geeigneten Netzwerkpartners befanden sich nicht im Einsatz. Vor Beginn der vertiefenden Zusammenarbeit innerhalb des Netzwerks war es insofern nötig, passende Geschäftsprozesse zu etablieren, die eine effiziente und damit wettbewerbsfähige Zusammenarbeit zuließen. Aufgrund des jungen Bestehens des Netzwerks und der damit verbundenen fehlenden Kooperationserfahrung lag es nahe, auf idealtypische Netzwerkprozesse mit entsprechender netzwerkspezifischer ITUnterstützung zurückzugreifen. Mit anderen Worten ausgedrückt wurde nach einer integrierten IT-Lösung gesucht, die einen idealtypischen Auftragsvergabeprozess für Netzwerke beinhalten sollte, womit sich aufgrund der geringen Kooperationserfahrung die Aneignung von unter Umständen weniger effizienten Prozessen vermeiden ließ. Zur Realisierung wählte VisQuaNet eine integrierte Standardsoftware aus, mittels dieser der vollständige Vergabeprozess sowie die Auftragssteuerung abgedeckt wurden. Die Architektur der gewählten Lösung ist dabei zum Applikations-Sharing zu zählen. So kennzeichnet sich die Lösung durch eine umfangreiche Abdeckung des Vergabeprozesses, wobei die Anwendung auf einem zentralen Server liegt und die Partnerunternehmen darauf über das Internet zugreifen können. Zusammengesetzt ist die integrierte Lösung aus Modulen, die die einzelnen Funktionen des enthaltenen Prozesses unterstützen.

Metamodell Zentrales Element des Metamodells der VisQuaNet-Integration ist das integrierte Anwendungssystem. Dieses wird von den Partnern, die das Netzwerk bilden, eingesetzt. Durch den im integrierten Anwendungssystem enthaltenen Funktionsumfang wird der Prozess, den die Netzwerkpartner bearbeiten, definiert. Vom integrierten Anwendungssystem wird ebenfalls mehrheitlich die Prozesssteuerung vorgenommen. Zusammengesetzt ist die Integrationslösung aus mehreren miteinander verbundenen Modulen. Diese beinhalten die Funktionen, die zur Prozessdurchführung

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

65

benötigt werden. Darüber hinaus sind im System die Daten enthalten, die zur Unterstützung des Prozesses benötigt werden. Die Daten stellen den In- bzw. Output der Funktionen dar. In Abb. 2.2.2.4/1 ist das Metamodell der VisQuaNet-Integration grafisch dargestellt. führt aus / löst aus

Partner

ist Teil von

Netzwerk

nutz

Prozess

Anwendungssystem

Modul

Daten

ist In-/ Output

ist verbunden mit

beinhaltet

beinhaltet

definiert / steuert

besteht aus

Funktion ist verbunden mit

Abb. 2.2.2.4/1: Metamodell der VisQuaNet-Integration

Aktivitäten- und Ergebnismodell Das Vorgehen der VisQuaNet-Integration lässt sich in drei Phasen (1) Systemanalyse (2) Systemvorstellung und (3) Simulation und Evaluation unterteilen, die im Folgenden nachgezeichnet werden. Systemanalyse Zunächst wurde der Markt möglicher IT-Lösungen für Netzwerke begutachtet. Dabei stand die Frage im Vordergrund, welche Systeme möglicherweise die Netzwerkarbeit unterstützen könnten, ohne zuvor mögliche Problembereiche zu untersuchen. Im Rahmen dieser Systemanalyse wurde ein integriertes Anwendungssystem zur Unterstützung des Auftragsprozesses ermittelt. Systemvorstellung In einem weiteren Schritt wurde die aufgefundene Lösung dem Netzwerk im Rahmen eines Workshops vorgestellt und der mögliche Einsatz zur Unterstützung des Auftragsvergabeprozesses diskutiert. Im Kern ließ sich dadurch ermitteln, inwiefern sich das System vor dem Hintergrund der von den jeweiligen Netzwerkpartnern angebotenen Leistungen überhaupt nutzen ließe. Darüber hinaus konnten die entstehenden Kosten für die Realisierung und damit die Wirtschaftlichkeit betrachtet und mögliche Einsatzszenarios für das Netzwerk aufgedeckt werden. Abgeschlossen wurde die

66

Grundlagen und Methodenanforderungen

erste Phase schließlich mit der Einigung auf eine grundsätzliche Eignung der Lösung und auf die Durchführung einer vertiefenden Evaluation. Simulation und Evaluation Mittels eines simulierten Einsatzes erfolgte die Evaluation der integrierten Lösung. Neben der Untersuchung des enthaltenen Funktionsumfangs ließen sich durch die Simulation die nötigen Anpassungen an das Netzwerk aufdecken. Zum Abschluss der Simulation stand die Einigung auf die integrierte Lösung und die Vergabe des Auftrags zur Implementierung.

Techniken Das Integrationsvorgehen von VisQuaNet kennzeichnet sich durch eine geringe methodische Unterstützung, da sich lediglich zwei Techniken im Ansatz auffinden lassen. Die Begutachtung des Systems wurde im Rahmen eines Workshops vorgenommen. Durch eine eingesetzte Testversion und die Simulation von Kooperationsprozessen wurde die Eignung der integrieren Lösung ermittelt. Aufgedeckt wurde dabei, inwiefern die enthaltenen Funktionen den Bedarf des Netzwerks widerspiegeln sowie welche nötigen Anpassungen für den Einsatz im Netzwerk nötig wären. Die Simulation wurde in zwei Etappen durchgeführt. In einem ersten Schritt wurden die unterstützten Kooperationsprozesse lediglich vom Netzwerkkoordinator und dem externen Anbieter der Lösung simuliert. In einem weiteren Schritt wurden die Netzwerkpartner zur Simulation hinzugezogen.

Rollenmodell Im Rahmen des Integrationsvorgehens von VisQuaNet finden sich drei wesentliche Rollen. Die Netzwerkkoordinatoren stellten die Schnittstelle zwischen den Netzwerkpartnern und den externen Anbietern dar. Sie nahmen dazu eine koordinierende und beratende Rolle ein. Die Netzwerkpartner hingegen waren die Projektverantwortlichen. Letztendlich oblag ihnen die Entscheidung über den Einsatz des Systems und die gewünschten Anpassungen. Des Weiteren nahmen sie eine unterstützende Rolle bei der Ermittlung der benötigen Anpassungen durch die Beteiligung an der Simulation ein. Schließlich übernahm eine externe Unternehmensberatung eine beratende Rolle bei der Systemvorstellung, der Ermittlung der nötigen Anpassung und der spätren Implementierung des Systems. 2.2.3 Gegenüberstellung der Fallstudien Anhand der vorangestellten Analyse der Integrationsmethoden erfolgt im Weiteren ihre Gegenüberstellung. Die Strukturierung der Gegenüberstellung wird durch das

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

67

der Methodenanalyse vorangestellte Raster vorgegeben.231 Zur detaillierten Betrachtung der Methoden wurde das zuvor grobe Raster für die Gegenüberstellung verfeinert. Ableiten lässt sich diese Verfeinerung aus den identifizierten Bestandteilen des Integrationsvorgehens in der Praxis. Das verfeinerte Raster ist in Abb. 2.2.3/1 dargestellt. Komponente Metamodell

Aktivitäten und Ergebnisse

Merkmal

Fragestellung

Gestaltungsfelder

Welche Gestaltungsfelder sind vom Vorgehen betroffen?

Allgemeines Vorgehen

Wie kennzeichnet sich das allgemeine Vorgehen?

Dokumentation der Identifizierung von Wie wird die Identifizierung der Integrationsbereichen Integrationsbereiche dokumentiert? Dokumentation der Bewertung von Integrationsbereichen

Wie wird die Bewertung der Integrationsbereiche dokumentiert?

Dokumentation der Konzeption von Integrationsbereichen

Wie wird die Konzeption der Integrationsbereiche dokumentiert?

Identifizierung des Integrationsbereichs

Wie erfolgt die Identifizierung von Integrationsbereichen?

Ermittlung des Funktionsumfangs

Anhand welcher Kriterien wird der Funktionsumfang ermittelt?

Ermittlung nicht-funktionaler Anforderungen

Wie erfolgt die Ermittlung nicht-funktionaler Anforderungen?

Auswahl der Integrationsarchitektur

Anhand welcher Kriterien wird die Auswahl der Integrationsarchitektur vorgenommen?

Bewertung von Integrationslösungen

Welches Vorgehen wird zur Bewertung der Integrationslösungen gewählt?

Konzeption der Integrationslösung

Wie erfolgt die Konzeption der angestrebten Lösung?

Rollen bei Integrationsprojekten

Wie ist die organisatorische Ausgestaltung der Integration?

Beteiligte Netzwerkpartner

Welche Netzwerkpartner sind am Integrationsprojekt beteiligt?

Techniken

Rollen

Abb. 2.2.3/1: Verfeinertes Raster zur Gegenüberstellung der Integrationsmethoden

Gestaltungsfelder Im Hinblick auf die Gestaltungsfelder lassen sich bei den untersuchten Vorgehensweisen zur Integration in der Praxis zwei Ansätze identifizieren. Beim Vorgehen von KFS und VisQuaNet erfolgt die Integration ohne weit reichende Eingriffe in die dezentralen Anwendungssysteme der Netzwerkpartner. Vielmehr wird auf eine erset-

231

Vgl. Kapitel 2.2.1.

68

Grundlagen und Methodenanforderungen

zende Integrationslösung zurückgegriffen, bei der sämtliche für einen Prozess notwendige Funktionen in die Lösung integriert sind, so dass keine weiteren Anwendungssysteme benötigt werden. Bei der integrierten Lösung von VisQuaNet liegt lediglich eine äußerst lose Kopplung zum Kommunikationssystem der Partnerunternehmen vor, die durch E-Mails über neue Ausschreibungen im System informiert werden. Das Vorgehen bezieht sich im Kern entsprechend auf die zu entwickelnde Lösung ohne die Altsysteme einzubeziehen. Im Gegensatz dazu verbindet bei Biege und dem Vertriebsnetzwerk die gewählte Lösung die ehemals bestehenden Anwendungssysteme. Dies wird im Falle des Biege-Vorgehens durch die Nutzung bereits vorhandener Schnittstellen der Anwendungssysteme auf Partnerseite ermöglicht. Eine Anpassung dieser Systeme wird dafür allerdings nicht vorgenommen. Im Rahmen der Integrationslösung des Vertriebsnetzwerks wurde hingegen eine andere Variante der Integrationslösungen gewählt. Sie kennzeichnet sich im Kern durch eine Integration bei der die Anpassung der bestehenden Systeme erforderlich ist. Entsprechend sind die bestehenden Anwendungssystemlandschaften in Form der Schnittstellenkonfiguration bzw. der Anpassung von Systemen Gestaltungsfelder dieses Vorgehens (vgl. zu den Ansätzen Abb. 2.2.3/2). Integrationslösungen

ersetzende Integrationslösung (Gestaltungsfeld: integriertes Anwendungssystem)

verbindende Integrationslösung

ohne Anpassung der bestehenden Systeme (Gestaltungsfeld: Integrationslösung)

mit Anpassung der bestehenden Systeme (Gestaltungsfelder: Integrationslösung und bestehende Anwendungssysteme)

Abb. 2.2.3/2: Gestaltungsfelder der Integrationslösungen der Fallbeispiele

Aktivitätenmodell Das gewählte Vorgehen zur Integration ähnelt sich bei den untersuchten Fallbeispielen stark. Kennzeichnen lässt es sich im Kern durch (a) den wiederholt anzutreffenden Schritt der Identifizierung von Integrationsbereichen, (b) die Ermittlung des benötigten Funktionsumfangs der Integrationslösung, (c) die Bewertung von Umsetzungs-

Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken

69

varianten und schließlich (d) die Konzeption einer Lösung. Unterschiede äußern sich vor allem im Hinblick auf drei Aspekte. Zum einen ist die Reihenfolge der Aktivitäten nicht zwangsläufig identisch. Beispielsweise folgt beim Vertriebsnetzwerk die Wirtschaftlichkeitsuntersuchung nach der Konzeption der Integrationslösung. Im Gegensatz dazu wird bei KFS die Wirtschaftlichkeitsbetrachtung der Konzeption vorgezogen. Zum anderen zeigen sich Unterschiede im Hinblick auf den Detaillierungsgrad der Ausgestaltung der einzelnen Aktivitäten. Beim Vertriebsnetzwerk etwa werden die einzelnen Aktivitäten im Detail durchgeführt. Im Rahmen des BiegeIntegrationsvorgehens wird hingegen lediglich die Konzeption der Integrationslösung im Detail vorgenommen und die weiteren Aktivitäten weniger stark fokussiert. Darüber hinaus lassen sich Unterschiede beim Vergleich des allgemeinen Vorgehens im Hinblick auf eine vorab vorgenommene Planung des Integrationsprojekts antreffen. So herrschte bei Biege und VisQuaNet eine weitgehende Unwissenheit über das Vorgehen im Rahmen eines Integrationsprojekts. Bekannt waren lediglich die Problemstellung und das angestrebte Ziel, nicht jedoch der Weg dahin. Anders gestaltete sich dieser Sachverhalt im Falle des Integrationsvorgehens bei KFS und dem Vertriebsnetzwerk, die vorab die durchzuführenden Aktivitäten definierten. Jedoch wurden auch diese nicht im Detail, etwa gemäß den Vorgehensweisen des Projektmanagements geplant, gesteuert und kontrolliert.

Ergebnismodell Allen Fallstudien gemein ist eine geringe Dokumentation der Ergebnisse. So werden häufig die Ergebnisse von Aktivitäten kaum oder gar nicht festgehalten. Zwischen den Fallstudien zeigen sich im Hinblick auf das Dokumentationsmodell trotzdem Unterschiede im Detail. Diese werden im Hinblick auf die Art der Dokumente sowie auf den Formalisierungs- und Detaillierungsgrad deutlich. Häufiger anzutreffende Dokumente beim Integrationsvorgehen waren Geschäftsprozessbeschreibungen sowie Pflichtenhefte.

Techniken Aus der Gegenüberstellung der eingesetzten Techniken innerhalb des Integrationsvorgehens der Fallstudien ergibt sich ein heterogenes Bild. Innerhalb keiner der Fallstudien konnte eine methodische Unterstützung für sämtliche Phasen aufgedeckt werden. Phasen, denen nur geringfügige methodische Unterstützung zukommt, beinhalten eine Evaluierung von Integrationsbereichen, eine Ermittlung nicht funktionaler Anforderungen sowie eine Auswahl der Integrationsarchitektur. Innerhalb der Fallstudien erfahren hingegen verstärkt die Phasen „Ermittlung des Funktionsumfangs“ sowie „Konzeption der Integrationslösung“ eine methodische Unterstützung.

70

Grundlagen und Methodenanforderungen

Die Identifizierung von Integrationsbereichen wird im Falle des Vertriebsnetzwerks und KFS durch eine Prozessanalyse unterstützt. Dabei werden die einzelnen Prozessschritte sowie die eingesetzten Anwendungssysteme erfasst und in eine chronologische Reihenfolge gebracht. Im Falle des Vertriebsnetzwerks wurde die Ermittlung der Prozesse durch Experteninterviews unterstützt. Unterschiedlich zeigt sich die methodische Unterstützung bei der Ermittlung des Funktionsumfangs der Integrationslösung. Parallelen werden lediglich im Falle von Biege und KFS sichtbar, die den Funktionsumfang anhand einer simulierten Nutzung des integrierten Systems mithilfe eines Pilottests ermittelten. Dieser wurde im Falle von KFS zusätzlich zur Ermittlung von nicht-funktionalen Anforderungen der angestrebten Lösung eingesetzt. Neben der Simulation lassen sich jedoch weitere Ansätze zur Ermittlung des Funktionsumfangs aufdecken. Darunter finden sich zum einen Ansätze, die vom angestrebten Prozess kommend den Funktionsumfang ermitteln, sowie zum anderen Ansätze, die ausgehend vom bestehenden Prozess und seinen Schwachstellen auf den zukünftigen Funktionsumfang schließen. Für die Konzeption der Integrationslösung lässt sich ebenfalls eine unterschiedliche methodische Unterstützung finden. Beim Vorgehen von Biege und KFS wurden dafür Pflichtenhefte erstellt, welche die wesentlichen Anforderungen an die zu entwickelnde Lösung beschreiben. Im Gegensatz hierzu wurde die Konzeption der angestrebten integrierten Lösungen anhand des ermittelten Soll-Prozesses abgeleitet.

Rollenmodell Im Hinblick auf das dem Integrationsvorgehen zugrunde liegende Rollenmodell lassen sich anhand der Fallstudien zwei Ansätze identifizieren. Zum einen findet sich eine eher hierarchisch aufgestellte Organisation der Integrationsprojekte. Diese kennzeichnet sich durch die Rollenverteilung mit einem verantwortlichen Projektleiter und diesem unterstellten Projektmitarbeitern. Im Gegensatz hierzu werden derartige Vorgehen deutlich, bei denen auf eine hierarchische Organisation verzichtet wurde und ein Projektteam aus mehrheitlich gleichberechtigten Mitarbeitern ohne Weisungsbefugnisse das Integrationsprojekt durchführt. Wird zusätzlich bei der Analyse der Rollen beim Integrationsvorgehen auf die beteiligten Netzwerkpartner eingegangen, so lassen sich ebenfalls zwei grundsätzliche Ansätze identifizieren. Zum einen findet sich der Fall, bei dem der fokale Netzwerkpartner das Integrationsprojekt im Wesentlichen vorantreibt und die Partnerunternehmen eine untergeordnete Rolle einnehmen. Daneben existiert ein weiterer Fall, bei dem Netzwerkkoordinatoren als Schnittstelle zwischen den Netzwerkpartnern und netzwerkexternen Projektbeteiligten fungieren. Dabei nehmen sie eine vertretende

Ableitung netwerkspezifischer Methodenanforderungen

71

und beratende Rolle ein, ohne die vollständige Verantwortung und Entscheidungsgewalt übertragen zu bekommen.

Metamodell

In Abb. 2.2.3/3 ist die Gegenüberstellung der Fallbeispiele in der Übersicht zusammengefasst.

Gestaltungsfelder

BIEGE

Vertriebsnetzwerk

KFS

VisQuaNet

einheitliche Datenbasis und Schnittstelle

Digitalisierungstechnologie, standardisiertes Datenformat, bestehende Anwendungssystemlandschaften

integriertes Anwendungssystem

integriertes Anwendungssystem

Aktivitäten- und Ergebnismodell

4 Phasen; Identifizierung Æ allgemeines Vorgehen Eingrenzung Æ Konzeption Æ Realisierung unstrukturierte Dokumentation der Textdokumente Identifizierung von IntegrationsÆnicht formalisiert bereichen grob

Techniken

4 Phasen;

Innovationsvorschlag Æ Prozessanalyse und -konzeption Æ Wirtschaftlichkeitsanalyse Projektplan

Abgrenzung Æ Definition Æ Pilotierung Æ Einführung Geschäftsprozesse

3 Phasen; Systemanalyse Æ Vorstellung Æ Simulation / Evaluation

Æ teilweise formalisiert grob

Æ teilweise formalisiert; detailliert

Preisübersicht

Wirtschaftlichkeitsermittlung

Æ nicht formalisiert grob

Æ nicht formalisiert detailliert

Pflichtenheft

Prozessmodell

Pflichtenheft

Liste nötiger Anpassungen

Æ teilweise formalisiert grob

Æ fromalisiert; detailliert

Æ teilweise formalisiert; detailliert

Æ nicht formalisiert grob

Identifizierung des Integrationsbereichs

-

Experteninterviews; Prozessanlayse

Prozessanalyse

-

Evaluation des Integrations-bereichs

-

verkürzte Kosten- / Nutzenanalyse

-

-

Analyse-Synthese-Schema; Pilottest

Schwachstellenanalyse

Prozessszenarien; Pilottest

Simulation

-

-

Pilottest

-

Softwareauswahlprozess

-

-

Workshop zur Vorstellung der Integrationslösung

-

Wirtschaftlichkeitsanalyse auf Kosten- / Nutzenbasis sowie ROI

-

-

Pflichtenheft

Konzeption des Soll-Prozesses und Soll-Anwendungssysteme

Pflichtenheft

-

Projektteam; Nutzer; externe Berater

Projektteam, externer Anbieter

Netzwerkkoordinator; Netzwerkpartner

Netzwerkkoordinator

Dokumentation der Bewertung der Integrationslösung Dokumentation der Konzeption der Integrationslösung

Ermittlung des Funktionsumfangs Ermittlung nichtfunktionaler Anforderungen Auswahl der Integrationsarchitektur Bewertung von Integrations-lösungen

Konzeption der Integrationslösung

Rollenmodell

3 Phasen;

beteiligte Akteure

beteiligte Netzwerkpartner

Projektleiter; Projektleiter; Projektmitarbeiter; Projektmitarbeiter; Nutzer IT- / Technologieexperte; Nutzer

fokaler Partner; Netzwerkpartner

fokaler Partner

Vorstellungsunterlagen -

Æ nicht formalisiert grob

Abb. 2.2.3/3: Gegenüberstellung der Fallbeispiele

2.3

Ableitung netwerkspezifischer Methodenanforderungen

Aus den vorgestellten Fallbeispielen des vorherigen Abschnitts sowie aus den einführend vorgestellten Begriffen der Unternehmensnetzwerke und zwischenbetriebli-

72

Grundlagen und Methodenanforderungen

chen Anwendungssystemintegration leiten sich Anforderungen an eine Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken ab. Gegliedert anhand der Komponenten des Method Engineerings stellt der folgende Abschnitt diese Methodenanforderungen vor. Gestaltungsfelder Zwei zentrale Hinweise für die Methodenanforderungen leiten sich aus den Architekturen der zwischenbetrieblichen Integration sowie aus dem analysierten Integrationsvorgehen der Praxis ab. 1. Unterstützung unterschiedlicher Integrationsmechanismen: Der erste Hinweis ergibt sich aus den möglichen Varianten, die Integration zu realisieren. Dazu wurden in den Grundlagen drei übergeordnete Architekturen vorgestellt.232 Zeigen konnten die Fallstudien, dass bei den Unternehmensnetzwerken sämtliche in den Grundlagen vorgestellten Architekturvarianten zum Einsatz kommen. Daraus ergibt sich als erste Anforderung einer Methode zur Integrationsplanung und -bewertung die Berücksichtigung unterschiedlicher Architekturvarianten zur Integration innerhalb der Methode. 2. Berücksichtigung der Anpassungsmöglichkeiten bestehender Systeme: Darüber hinaus ließen sich im Hinblick auf die Gestaltungsfelder unterschiedliche Integrationsvarianten finden, wie etwa im Fall des Vertriebsnetzwerks eine Anpassung der bereits eingesetzten Systeme der Partnerunternehmen, oder die Variante, bei der die bereits eingesetzten Systeme nicht anzupassen sind, wie bei Biege. Als Methodenanforderung leitet sich entsprechend die Berücksichtigung von Integrationsvarianten mit und ohne eine nötige Systemanpassung – etwa je nach Gegebenheit im Netzwerk – ab. Aktivitäten- und Ergebnismodell Neben den Anforderungen an die Gestaltungsfelder lassen sich Anforderungen an das Aktivitäten- und Ergebnismodell aufdecken. 1. Unterstützung dreier Kernaktivitäten: Aus der Untersuchung des allgemeinen Vorgehens in der Praxis leiten sich zunächst drei Kernaktivitäten einer Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken ab. Die Kernaktivitäten umfassen die Identifizierung von Integrationsbereichen, der die Konzeption einer Integrationslösung sowie deren Bewertung folgt (vgl. Abb. 2.3/1).

232

Vgl. Kapitel 2.1.2.3.

Ableitung netwerkspezifischer Methodenanforderungen

73

BIEGE

Vertriebsnetzwerk

KFS

VisQuaNet

Identifizierung

Konzeption

Bewertung

Netzwerkmethode

Abb. 2.3/1: Kernaktivitäten des Integrationsvorgehens

2. Inkrementelles Vorgehen mit Abbruchstellen: Aus einer detaillierten Betrachtung der Anordnung und aus Wiederholungen der Aktivitäten lassen sich weitere Hinweise für eine Integrationsmethode für Netzwerke ableiten. Die Betrachtung der Reihenfolge der Aktivitäten deckt erste Unterschiede auf. Ausgangspunkt des Vorgehens ist die Identifizierung von Integrationsbereichen. Dieser kann entweder zunächst die Bewertung und dann die Konzeption oder zuerst die Konzeption und daraufhin die Bewertung von Integrationslösungen folgen (vgl. Abb. 2.3/2). Variante 1

Variante 2 1

1

Identifizierung

2

Identifizierung

2

Konzeption

3

Bewertung

3

Bewertung

Konzeption

z.B. Vertriebsnetzwerk

z.B. BIEGE

Abb. 2.3/2: Anordnungsvarianten der Kernaktivitäten für die Integration

Zusätzlich kennzeichnet sich das Vorgehen in der Praxis durch die wiederholte Durchführung von Aktivitäten. Deren Ausgestaltung wird bei der Wiederholung jedoch nicht vollkommen identisch vorgenommen. Vielmehr erfolgt die Durchführung zu Projektbeginn zunächst überblicksartig. Mit zunehmender Projektdauer steigt der Detaillierungsgrad der wiederholten Aktivitäten, womit

74

Grundlagen und Methodenanforderungen

die Genauigkeit der erhaltenen Ergebnisse steigt. Entsprechend sind die Aktivitäten in der Praxis im Kern durch ein überwiegend inkrementelles Vorgehen gekennzeichnet. Dabei werden die im Rahmen eines Zyklus erhaltenen Ergebnisse zusätzlich im Hinblick auf die zu erwartende Projektvorteilhaftigkeit hinterfragt. Folglich werden Projekte, die der kritischen Überprüfung nicht standhalten, frühzeitig abgebrochen. Diese Erkenntnisse lassen sich als Anforderungen an eine Methode zur Integrationsplanung und -bewertung übernehmen. Entsprechend soll die Methode inkrementell aufgebaut sein und mögliche Abbruchstellen sollten berücksichtigt werden (vgl. Abb. 2.3/3).

Identifizierung Bewertung Konzeption

möglicher Abbruch

Identifizierung Bewertung Konzeption

Identifizierung Bewertung Konzeption

möglicher Abbruch

Abb. 2.3/3: Anforderungen an das Aktivitätenmodell

3. Zunehmender Detaillierungsgrad der Ergebnisdokumente sowie Ersetzung der informaler durch formale bei zunehmender Projektdauer: Neben dem Aktivitätenmodell leiten sich aus den Fallbeispielen Anforderungen an das Ergebnismodell einer Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken ab. Grundsätzlich gilt es informale Ergebnisdokumente, etwa in Form textueller Beschreibungen, sowie formale Ergebnisdokumente, etwa in Form von Datenflussdiagrammen, zu berücksichtigen.233 Dem steigenden Detaillierungsgrad der Aktivitäten bei zunehmender Projektdauer folgend, finden sich informale grobe Ergebnisdokumente vermehrt zu Beginn des Projekts, mit zunehmender Projektdauer werden sie von formalen und detaillierten Ergebnisdokumenten ersetzt.

Techniken Ferner leiten sich aus den Fallstudien Anforderungen an zu enthaltene Techniken einer Methode für die Integrationsplanung und -bewertung ab.

233

Zu informalen und formalen Dokumenten vgl. Balzert (2000), S. 110.

Ableitung netwerkspezifischer Methodenanforderungen

75

1. Bereitstellung einer methodischen Unterstützung für alle Projektphasen Die Untersuchung der vorgestellten bzw. eingesetzten Techniken zur Integration zeigt ein heterogenes Bild. Bei keiner Fallstudie wurde durchgängig bei allen Projektphasen auf detaillierte Handlungsanweisungen zurückgegriffen. Nichtsdestotrotz konnten für alle wesentlichen Projektphasen Techniken zu deren Unterstützung identifiziert werden. Entsprechend sollte sich eine Methode für die Integrationsplanung und -bewertung auf die Bereitstellung von möglichen Techniken für alle relevanten Projektschritte konzentrieren (vgl. Abb. 2.3/4).

Identifizierte Techniken in der Praxis

Netzwerkmethode

BIEGE

Vertriebsnetzwerk

KFS

VisQuaNet

Techniken

-

3

3

-

Identifizierung des Integrationsbereichs

3

-

3

-

-

Evaluation des Integrationsbereichs

3

3

3

3

3

Ermittlung des Funktionsumfangs

3

-

-

3

-

Ermittlung nichtfunktionaler Anforderungen

3

3

-

-

3

Auswahl der Integrationsarchitektur

3

-

3

-

-

Bewertung von Integrationslösungen

3

3

3

3

-

Konzeption der Integrationslösung

3

Abb. 2.3/4: Anforderungen an die zu enthaltenden Techniken der Integrationsmethode

2. Steigender Detaillierungsgrad: Typischerweise sind die aufgedeckten Techniken des Integrationsvorgehens in der Praxis durch eine geringe Formalisierung geprägt. Vielmehr kennzeichnen sie sich durch den Verzicht auf eine hohe Komplexität zu Lasten eines vollkommen exakten Ergebnisses. Jedoch wird auch ersichtlich, dass mit zunehmender Projektdauer der formale Anspruch an die gewählten Techniken steigt. Entsprechend bedarf es einer geeigneten Abwägung der Wirtschaftlichkeit des Einsatzes einer Technik im Vergleich zu ihrer Genauigkeit. Erst im späteren Projektverlauf und mit wiederholender Überprüfung der Vorteilhaftigkeit des weiteren Vorgehens finden sich detaillierte Techniken. Im Anschluss an die bereits vorgestellten Anhaltspunkte des Vorgehens- und Ergebnismodells lässt sich entsprechend ein zu-

76

Grundlagen und Methodenanforderungen

nehmender Detaillierungsgrad der enthaltenen Techniken einer Methode zur Integrationsplanung und -bewertung bei steigender Projektdauer ableiten (vgl. 2.3/5). Detaillierungsgrad der Technik

Projektdauer

Abb. 2.3/5: Steigender Detaillierungsgrad der Techniken

Rollenmodell Schließlich leiten sich aus der Einführung in die Unternehmensnetzwerke und den Fallstudien Anforderungen an das Rollenmodell ab. 1. Berücksichtigung von Varianten der Projektorganisation: Die Betrachtung der organisatorischen Ausgestaltung von Integrationsprojekten deckt im Anschluss an die unterschiedlichen Steuerungsformen von Netzwerken aus den Grundlagen zwei Zugänge auf. Neben der hierarchischen Organisation von Integrationsprojekten ließ sich ebenfalls eine heterarchische Organisation finden. Gemäß diesen Erkenntnissen leiten sich Anforderungen an das Rollenmodell einer Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken ab. Zunächst bedarf es der Berücksichtigung unterschiedlicher organisatorischer Ausgestaltungsformen, so dass die Methode für fokale Netzwerke mit einer hierarchischen Organisation ebenso wie für polyzentrische Netzwerke mit einer heterarchische Organisation nutzbar ist. 2. Berücksichtigung von Varianten der Rollenbesetzung: Darüber hinaus werden aus den Fallstudien unterschiedliche Beteiligte innerhalb und außerhalb des Netzwerks ersichtlich. So sind an der Integration etwa interne Akteure wie Netzwerkkoordinatoren, fokale Netzwerkpartner oder nicht-fokale Netzwerkpartner beteiligt. Daneben finden sich zusätzlich externe Akteure wie Softwareanbieter oder Beratungsunternehmen. Demzufolge hat die Methode zu thematisieren, welche internen Netzwerkpartner zwingend Rollen übernehmen müssen, die nicht an andere interne (nicht-fokaler Partner, Koordinator) oder an netzwerkexterne Partner abgegeben werden können. Abb. 2.3/6 stellt die vorgestellten Methodenanforderungen zusammenfassend dar.

Ableitung netwerkspezifischer Methodenanforderungen

Rollenmodell

Techniken

Aktivitäten- und Ergebnismodell

Gestaltungsfelder

Anforderung

Unterstützung unterschiedlicher Integrationsmechanismen

Berücksichtigung der Anpassungsmöglichkeiten bestehender Systeme

Anpassung des zugrunde liegenden Ablaufs

Beinhaltet die Kernaktivitäten Identifizierung, Konzeption und Bewertung

inkrementelles Vorgehen mit Abbruchstellen Ersetzen der informalen durch formale Ergebnisdokumente bei zunehmender Projektdauer Bereitstellung einer methodischen Unterstützung für alle Projektphasen

Steigener Detaillierungsgrad der Techniken bei zunehmender Projektdauer

Berücksichtigung von Varianten der Projektorganisation

Berücksichtigung von Varianten der Rollenbesetzung

Abb. 2.3/6: Zusammenfassung der Methodenanforderungen

77

3 Untersuchung bestehender Integrationsmethoden Wie bereits in der Einleitung beschrieben, finden sich unter den bestehenden Ansätzen zur Integration von Anwendungssystemen innerhalb der Literatur keine Methoden, die explizit auf die organisatorischen Besonderheiten von Unternehmensnetzwerken ausgerichtet sind. Nichtsdestotrotz ist anzunehmen, dass die Ansätze der Literatur Bestandteile enthalten, die sich vom jeweils beschriebenen Kontext aus auch auf Fälle mit netzwerkspezifischen Besonderheiten übertragen lassen. Zur Klärung dieser Frage untersucht das vorliegende Kapitel Integrationsmethoden aus der Literatur. Dazu wird in Kapitel 3.1 zunächst ein allgemeiner Überblick über die Integrationsmethoden innerhalb der Literatur geschaffen, woraufhin in Kapitel 3.2 vier ausgewählte Methoden im Detail untersucht werden. Kapitel 3.3 beurteilt schließlich die Eignung der untersuchten Methoden im Hinblick auf die in Kapitel 2.3 vorgestellten Anforderungen. 3.1

Bestehende Integrationsmethoden im Überblick

3.1.1 Zur Auswahl der Integrationsmethoden Den Ausgangpunkt der Analyse stellt die Methodenauswahl dar. Als Methoden werden im Rahmen der vorliegenden Arbeit sämtliche Beiträge gefasst, die Hinweise auf eine „planmäßige Art und Weise des Handelns mit überprüfbaren Ergebnissen“ geben.234 Zu den Integrationsmethoden werden daher solche Ansätze gezählt, welche die folgenden Anforderungen erfüllen. Sie müssen •

explizit auf die Anwendungssystemintegration abzielen,

•

explizite Handlungshinweise für ein Integrationsvorgehen beinhalten,

•

allgemeiner Natur sein und dürfen sich nicht auf einen Einzelfall beziehen.235

Grundlage der vorgenommenen Methodengegenüberstellung bilden Publikationen wie Konferenzbeiträge, Dissertationen und Fachbeiträge.236 Aus diesen vorangestellten Anforderungen ergibt sich die in Abb. 3.1.1/1 dargestellte erste Auswahl der zu untersuchenden Integrationsmethoden.

234

235 236

Vgl. Chmielewicz (1994), S. 36; Pfohl/Stölzle (1996), S. 128; Becker et al. (2001), S. 5; Braun et al. (2005), S. 1296; Greiffenberg (2003), S. 962. Ähnlich Legner (1999), S. 32. Vgl. Reichmayr (2003), S. 12; Kremer (2004), S. 34. Zur Analyse wurden insofern nur Arbeiten gezählt, die frei zugänglich sind (vgl. Steffen (2002), S.102).

80

Untersuchung bestehender Integrationsmethoden

Integrationsmethoden Eine Entwicklungsmethodik für die überbetriebliche Integration von Anwendungssystemen

Mantel et al. (2004); Eckert / Schissler / Ferstl (2004); Mantel et al. (2002)

Integration von Informationssystemen

Holten (2003)

Architektur integrierter Informationssysteme: Grundlagen der Unternehmensmodellierung

Scheer (2002); Scheer (1998); Scheer (1991)

Modellierungsmethode zur Integration zwischenbetrieblicher Informationsflüsse

Steffen (2002)

Enterprise Application Integration

Linthicum (2000)

Konzeptionelle Integration heterogener Transaktionssysteme

Gassner (1996)

Integrationsmanagement

Stietz (1995)

Unternehmensübergreifende Datenmodellierung – der nächste Schritt der zwischenbetrieblichen Datenverarbeitung

Fischer (1993)

Unternehmensführung und Informationssystem: Der Ansatz des St. Galler Informationssystem-Managements

Österle / Brenner / Hilbers (1991); Hilbers (1992)

Electronic Data Interchange: A Total Management Guide

Emmelhainz (1990)

Abb. 3.1.1/1: Ermittelte Integrationsmethoden237

Die Analyse der aufgedeckten Integrationsmethoden kann anhand „inhaltlicher“ und „struktureller“ Charakteristika erfolgen.238 „Inhaltliche Charakteristika“ beziehen sich auf die der Integrationsmethode zugrunde liegende Integrationsdefinition. Anhand der Übereinstimmung mit der in Kapitel 2.1.2.2 vorgestellten Integrationsmerkmale erfolgt die Untersuchung der inhaltlichen Charakteristika der jeweiligen Integrationsmethode. Zusätzlich zu den inhaltlichen Kriterien lassen sich Methoden hinsichtlich der Vollständigkeit der jeweiligen methodischen Beschreibung unterscheiden. Als vollständig wird eine Methode im Rahmen der Untersuchung verstanden, wenn sie alle Komponenten des Method Engineerings enthält.239 Mithilfe „struktureller Charakteristika“ werden die ermittelten Integrationsmethoden entsprechend im Folgenden hinsichtlich ihrer methodischen Vollständigkeit untersucht. Dazu werden die Integrationsmethoden in Bezug auf die enthaltenen Komponenten des Method Engineerings überprüft.

237 238 239

Sortiert nach Aktualität. Zum Vorgehen vgl. etwa Bach et al. (1996), S. 81; Puschmann (2003), S. 14. Vgl. Legner (1999), S. 73.

Bestehende Integrationsmethoden im Überblick

81

3.1.2 Charakteristika der Integrationsmethoden

Eine Entwicklungsmethodik für die überbetriebliche Integration von Anwendungssystemen (FORWIN)240 Die vom Bayerischen Forschungsverbund Wirtschaftsinformatik (FORWIN) entwickelte Integrationsmethode zielt auf eine zwischenbetriebliche Integration ab. Dabei systematisiert sie die Kopplung von Anwendungssystemen durch eine Integrationsarchitektur mit sechs Ebenen sowie ein neun Schritte umfassendes Vorgehensmodell. Ausgangspunkt ist der überbetriebliche Geschäftsprozess auf oberster Ebene des Ebenenmodells (Ebene 1). Auf den darunter liegenden Ebenen liegen die zu integrierenden Anwendungssysteme (Ebene 2) sowie schließlich die Komponenten des Integrationsmechanismus (Ebene 3 - 6). Die FORWIN-Methode unterscheidet hinsichtlich ihrer inhaltlichen Charakteristika zwischen ereignis-, daten- und funktionsorientierten Kopplungsarchitekturen.241 Die Unterstützung der daten- und funktionsorientierten Kopplungsarchitektur weist auf eine Übereinstimmung der FORWIN-Methode mit der Daten- und Funktionsintegration hin. Die ereignisorientierte Architektur bezieht sich ferner auf die Integration mittels Nachrichten. Die dabei erreichte automatische Konvertierung von Daten entspricht der im Rahmen der Programmintegration vorgestellten Integration von Schnittstellen. Wie bereits dargelegt, stellt der überbetriebliche Geschäftsprozess den Ausgangspunkt der FORWIN-Methode dar. Die Integration der betrieblichen Funktionen von Geschäftsprozessen steht dabei im Vordergrund. Anhaltspunkte für eine vertikale oder innerbetriebliche Integration finden sich indes nicht. Gemäß den strukturellen Charakteristika beinhaltet die FORWIN-Methode mit der ausführlichen Darstellung des Vorgehensmodells Hinweise über die Aktivitäten und daraus resultierende Ergebnisdokumente.242 Innerhalb der jeweiligen Aktivitäten werden Detailanweisungen und damit gemäß dem Method Engineering Techniken vorgestellt. So wird beispielsweise der Verweis auf die Schritte zur Modellierung der überbetrieblichen Geschäftsprozesse vorgenommen.243 Auf Akteure sowie deren Rollen wird indes nicht eingegangen. Für jede Ebene ist schließlich ein zugrunde liegendes Metamodell enthalten.

240 241 242 243

Vgl. im Folgenden Mantel et al. (2004), S. 21-39. Vgl. Schissler et al. (2004), S. 15-16; Mantel/Schissler (2002), S. 171-172. Vgl. Schissler et al. (2004), S. 31-36. Vgl. Eckert et al. (2004), S. 46-49; Schissler et al. (2004), S. 25-26;

82

Untersuchung bestehender Integrationsmethoden

Integration von Informationssystemen (Holten)244 Im Beitrag von Holten zur Integration von Informationssystemen wird zunächst ein Überblick über Standards und Techniken zur Integration von Anwendungssystemen gegeben. Diese sind anhand der Phasen der Anwendungssystementwicklung in 1. Fachkonzeption, 2. DV-Konzeption und 3. Implementierung strukturiert. Darüber hinaus enthält der Beitrag Hinweise auf ein methodisches Vorgehen zur Integration. Dafür werden Integrationsansätze anhand eines Rahmensmodells mit drei Ebenen (Metaebene, Typenebene und Instanzebene) und drei Phasen (Fachkonzeption, DVKonzeption und Implementierung) systematisiert. Der Beitrag von Holten beschäftigt sich im Hinblick auf die inhaltlichen Charakteristika im Wesentlichen mit der Datenintegration. Dieser Fokus wird durch die dezidierte Auseinandersetzung mit dem auf XML basierenden Datenaustausch deutlich.245 Ferner thematisiert der Beitrag zumindest implizit die Funktionsintegration im Rahmen der Behandlung EAI-basierter Integrationsarchitekturen.246 Indes finden sich keine Hinweise auf die Programmintegration. Aussagen über die Richtung lassen sich im Beitrag Holtens nicht identifizieren. Bezüglich der Reichweite geht Holten auf die Entwicklung einer einheitlichen Beschreibung von Datentypen innerhalb eines Unternehmens bzw. zwischen Unternehmen ein.247 Strukturelle Charakteristika finden sich in der Methode von Holten in Form eines Vorgehensmodells durch die vorgenommene Unterscheidung in Fach- und DVKonzeption sowie Implementierung. Ebenfalls finden sich vermehrt Hinweise auf zu erstellende Ergebnisdokumente. Rollen gehen hingegen nicht aus dem Beitrag hervor und Techniken lediglich für die Phase der Fachkonzeption durch den Hinweis auf eine einheitliche Definition des Nachrichtenaustauschs anhand des SCORModells248. Ein Metamodell ist indes nicht vorhanden.

Architektur integrierter Informationssysteme (ARIS)249 ARIS stellt eine Methode zur Entwicklung und Optimierung integrierter betriebswirtschaftlicher Anwendungssysteme dar. Ein starker Fokus liegt dabei auf den jeweiligen Prozess, der dem integrierten Anwendungssystem zugrunde liegt. Die ARISArchitektur ist zunächst in drei Sichten (Daten-, Funktions- und Organisationssicht) 244 245 246 247 248

249

Vgl. im Folgenden Holten (2003), S. 41-52. Vgl. Holten (2003), S. 42-44. Vgl. Holten (2003), S. 44-46. Vgl. Holten (2003), S. 45. SCOR steht für Supply Chain Operation Reference und wird zur unternehmensinternen sowie -übergreifenden Beschreibung von Geschäftsprozessen verwendet (vgl. Werner (2002), S. 15-27; Heinzel (2001), S. 49-68). Vgl. im Folgenden Scheer (2002); Scheer (1991).

Bestehende Integrationsmethoden im Überblick

83

unterteilt, deren Zusammenhänge durch die Steuerungssicht als vierte Sicht festgehalten werden. Jede Sicht gilt es gemäß ARIS angemessen bei der Entwicklung integrierter Anwendungssysteme zu berücksichtigen, wozu jede Sicht in drei Phasen (1. Fach-, 2. DV-Konzeption und 3. Implementierung) entsprechend dem klassischen Prozess der Softwareentwicklung untereilt ist. Daten- und Funktionsintegration behandelt die in ARIS enthalte Daten- und Funktionssicht explizit. Ferner ist durch den Bezug auf Software-Komponenten (Componentware) auch die Programmintegration im Beitrag enthalten.250 Der Aufbau von ARIS stützt sich zudem auf ein Vorgangskettenmodell mit starkem Bezug auf den Wertschöpfungsprozess auf der Ebene der unternehmerischen Grundfunktionen.251 Dieses Vorgehen stimmt mit der horizontalen Integration überein. Des Weiteren werden durch die Thematisierung von Executive Information Systems Ansatzpunkte einer vertikalen Integration als zweites Merkmal der Integrationsrichtung aufgeführt. Hingegen steht die zwischenbetriebliche Integration nicht im Fokus. Das Vorgehen ist gemäß ARIS nach einer vorangestellten Vorgangskettenanalyse in drei folgende Phasen (Fach- und DV-Konzept sowie Implementierung) unterteilt. Diese sind jeweils für die drei ARIS zugrunde liegenden Sichten (Daten, Funktionen und Steuerung) zu durchlaufen. So lassen sich bei der Analyse der strukturellen Charakteristika von ARIS konkrete Hinweise zu durchzuführenden Aktivitäten und – in Form der erhaltenen Fach- und DV- sowie Implementierungskonzepte – zu Ergebnisdokumenten entnehmen. Zusätzlich werden für die jeweiligen Phasen und Sichten Techniken vorgestellt. Für ein Rollenmodell finden sich indes kaum Hinweise. Ebenfalls enthalten ist ein umfangreiches Metamodell, das sich auf die Elemente des integrierten Anwendungssystems bezieht.

Modellierungsmethode zur Integration zwischenbetrieblicher Informationsflüsse (MOVE)252 Der Beitrag von Steffen zielt auf die Entwicklung einer Methode zur Integration zwischenbetrieblicher Informationsflüsse ab. Die Modellierungsmethode besteht aus fünf verschiedenen Diagrammtypen (Transaktions-, Interaktions-, Nachrichten-, Sequenzsowie Regeldiagramm), für er jeweils ein spezifisches Vorgehen erarbeitet hat. Diesen Diagrammen liegt ein einheitlicher Entwurfsrahmen zugrunde, welcher sich an Leistungs-, Zahlungs- und Informationsflüssen einer zwischenbetrieblichen Transak-

250 251

252

Vgl. Scheer (2002), S. 98-102. Zu diesen gehören gemäß dem Wertschöpfungskettenmodell nach Porter Einkauf, Fertigung, Logistik, Marketing und Vertrieb sowie Nachbereitung (vgl. Porter (1990), S. 41). Vgl. im Folgenden Steffen (2002).

84

Untersuchung bestehender Integrationsmethoden

tion orientiert sowie einer Referenzbibliothek, die für alle Teilnehmer der zwischenbetrieblichen Integration standardisiert ist. Im Hinblick auf die inhaltlichen Charakteristika stimmt der Integrationsgegenstand gemäß Steffen lediglich mit der Datenintegration überein. MOVE zielt im Wesentlichen auf den zwischenbetrieblichen Austausch von Nachrichten ab. Die Integrationsrichtung wird im Beitrag von Steffen nicht explizit erwähnt. Die MOVE zugrunde liegende Transaktionsorientierung lässt allerdings auf eine starke Fokussierung der horizontalen Integration schließen. Hingegen konnten keine Hinweise auf die Eignung für eine vertikale Integration gefunden werden. Im Hinblick auf die Reichweite bezieht sich MOVE lediglich auf die zwischenbetriebliche Integration. Die strukturellen Komponenten lassen sich vor allem durch die im Beitrag von Steffen erarbeiteten Aktivitäten und die sich daraus ergebenden Ergebnisdokumente in Form der MOVE zugrunde liegenden fünf Diagramme entnehmen. Zusätzlich werden im Beitrag konkrete Techniken vorgeschlagen, die den Erhalt der Ergebnisdokumente unterstützen. Ein MOVE umfassendes Metamodell sowie Hinweise auf Rollen sind hingegen nicht ersichtlich.

Enterprise Application Integration (Linthicum)253 Linthicum geht in seinem Beitrag ausführlich auf das Phänomen EAI ein. Darunter wird allgemein der uneingeschränkte Zugriff auf Daten und Geschäftsvorgänge von sämtlichen angeschlossenen Anwendungssystemen eines Unternehmens verstanden.254 Im Fokus seiner Betrachtung stehen dabei verschiedene Varianten, wie etwa Data-Level EAI oder Application Interface-Level EAI. Zusätzlich enthält der Beitrag eine Vorgehenshinweise für die Einführung von EAI. Daneben stellt er technische Ausgestaltung der EAI zugrunde liegenden Middleware detailliert vor. Der im Beitrag von Linthicum betrachtete Integrationsgegenstand beinhaltet alle im Rahmen der vorliegenden Arbeit vorgestellten Integrationsobjekte. So geht er explizit auf die Integration von Daten als Data-Level EAI, Funktionen als Method-Level EAI und Programmen als Application Interface bzw. User Interface EAI ein. Wie beschrieben besteht EAI aus Sicht des Autors aus der Verknüpfung sämtlicher Anwendungssysteme eines Unternehmens. Daraus lässt sich sowohl die vertikale als auch die horizontale Integration ablesen. Auf deren Besonderheiten, wie etwa nötige Datenverdichtungen bei der vertikalen Integration, wird allerdings nicht explizit eingegangen. Im Hinblick auf die Integrationsreichweite wird im Beitrag von Linthicum

253 254

Vgl. im Folgenden Linthicum (2000). Vgl. Linthicum (2000), S. 3.

Bestehende Integrationsmethoden im Überblick

85

ausdrücklich sowohl die innerbetriebliche Integration, die im Fokus steht, als auch die zwischenbetriebliche Integration thematisiert.255 Weiterhin finden sich einige strukturelle Charakteristika im Beitrag. Im Vordergrund stehen dabei der zwölf Schritte umfassende Vorgehensplan im Sinne eines Vorgehensmodells sowie die sich daraus ergebenden rudimentär beschriebenen Ergebnisdokumente. Techniken lassen sich hingegen nur für zwei der zwölf Phasen identifizieren. Ebenso fehlen Hinweise auf spezifische Rollen bei der Einführung von EAI sowie ein Metamodell.

Konzeptionelle Integration heterogener Transaktionssysteme (Gassner)256 Gassner entwickelt in seiner Arbeit einen methodischen Ansatz zur Dokumentation der konzeptionellen Integration von Anwendungssystemen. Die konzeptionelle Integration ist eine Vorstufe der Integration und ist somit unabhängig von deren tatsächlichen technischen Realisierung. Die erstellte Dokumentation soll als Grundlage für die Integration von neuen oder bereits existierenden Anwendungssystemen dienen. Neben der Entwicklung eines objektorientierten Integrationsmodells geht Gassner zusätzlich auf ein Vorgehensmodell ein. Diese gliedert er zusammenfassend in vier Schritte:257 Als erster Schritt wird die Abgrenzung von Integrationsbereichen durch die Analyse von zu integrierenden Anwendungssystemen vorgeschlagen. Daran schließt sich als zweiter Schritt der Entwurf einer Soll-Integrationsbeziehung an. Die Integrationsbeziehungen der zu integrierenden Anwendungssysteme werden im dritten Schritt weiter spezifiziert, so dass im fünften Schritt schließlich die softwaretechnische Implementierung der Integration vorgenommen werden kann. Hinsichtlich des Integrationsgegenstands bezieht sich Gassners Ansatz auf die Daten- und Funktionsintegration. Im Hinblick auf Richtung und Reichweite der Integration lassen sich bei Gassner keine expliziten Aussagen finden. Deren Besonderheiten bei der Integration werden nicht berücksichtigt. Strukturelle Komponenten finden sich in Form eines Meta- und Vorgehensmodells sowie der Ergebnisdokumentation. Auf Techniken und Rollen wird im Verlauf der Arbeit hingegen nicht eingegangen.

255 256 257

Vgl. Linthicum (2000), S. 17. Vgl. im Folgenden Gassner (1996). Vgl. Gassner (1996), S. 161-162.

86

Untersuchung bestehender Integrationsmethoden

Integrationsmanagement (Stietz)258 Das Ziel der Arbeit von Stietz liegt in der Entwicklung eines Gestaltungsansatzes für ein CIM-Konzept.259 Dazu stellt er einen Projektmanagementansatz vor, der sich in drei Teile gliedert. Im ersten, als funktionelles Integrationsmanagement bezeichneten Teil sollen die Einflussgrößen einer CIM-Konzeption vorgestellt werden. Im institutionellen Management als zweitem Teil werden Fragen zur internen Projektstruktur sowie Beziehungen zu externen Einheiten erörtert. Im abschließenden dritten Teil (personelles Integrationsmanagement) behandelt Stietz Fragen zu den Projektbeteiligten sowie zur Projektstruktur. Der Integrationsgegenstand als Bestandteil der inhaltlichen Charakteristika beinhaltet lediglich die Datenintegration.260 Hinweise auf Funktions- und Programmintegration lassen sich somit nicht entnehmen. Explizit wird neben der horizontalen Integration auch auf die Integration von Management-Informations-Systemen und damit auf eine vertikale Integration eingegangen.261 Ferner ist sowohl die innerbetriebliche als auch die zwischenbetriebliche Integration Gegenstand des Beitrags.262 Strukturelle Charakteristika finden sich in der Arbeit von Stietz durch das ausgearbeitete Vorgehensmodell, aus dem sich die Aktivitäten gemäß des Method Engineerings ablesen lassen. Mitunter endet die Beschreibung einer Aktivität allerdings bei der Erläuterung ihrer Bedeutung. Auf das nötige Vorgehen wird somit nicht ausreichend eingegangen, so dass sich häufig keine Hinweise für Ergebnisdokumente finden.263 Ebenfalls sind nicht für alle Aktivitäten Techniken enthalten. Durch die Beschreibung der Aufbauorganisation eines CIM-Projekts wird hingegen auf Rollen umfangreich eingegangen. Ein Metamodell der Methode lässt sich jedoch bei Stietz nicht identifizieren.

Unternehmensübergreifende Datenmodellierung – der nächste folgerichtige Schritt der zwischenbetrieblichen Datenintegration (Fischer)264 Das Ziel des Beitrags von Fischer liegt in der Entwicklung eines unternehmensübergreifenden Datenmodells, etwa für eine Branche oder die beteiligten Unternehmen einer Supply Chain. Vorteile dabei werden in der sich damit vereinfacht durchführba258 259

260 261 262 263

264

Vgl. im Folgenden Stietz (1995). CIM steht für Computer Integrated Manufacturing, das für eine anwendungssystemgestützte Planung und Steuerung des Produktionsprozesses steht (vgl. Becker (1991)). Vgl. Stietz (1995), S. 15-16. Vgl. Stietz (1995), S. 21. Vgl. Stietz (1995), S. 146-148. Die Ausführungen zur Ableitung potenzieller Integrationsbereiche können dafür als Beispiel herangezogen werden (vgl. Stietz (1995), S. 140-148). Vgl. im Folgenden Fischer (1993).

Bestehende Integrationsmethoden im Überblick

87

ren zwischenbetrieblichen Integration gesehen. Für die Entwicklung des Datenmodells sind im Kern Schnittstellenerfordernisse, die sich aus der Systemlandschaft der beteiligten Unternehmen ergeben, zu einem übergreifenden Datenmodell zusammenzufassen. Dazu schlägt Fischer ein Vorgehen mit drei groben Schritten vor. Zu Beginn soll zunächst auf konzeptueller Ebene ein übergreifendes, grobes Datenmodell erstellt werden, welches in einem zweiten Schritt durch Attribute konkretisiert wird. Abschließend soll in einem dritten Schritt und auf logischer Ebene die DVtechnische Realisierung vorgenommen werden. Dabei ist die Definition der Nachrichtenstrukturen zur Datenübermittlung zwischen den Anwendungssystemen vorzunehmen. Dies erfolgt auf Basis der Attribute des zweiten Schritts und der Erstellung einer übergreifenden Datenbank, die alle Stammdaten (etwa sämtliche Produktdaten) enthält. Bei der Analyse der inhaltlichen Charakteristika ist für den Integrationsgegenstand festzustellen, dass Fischer lediglich auf die Datenintegration Bezug nimmt. Im Hinblick auf die Richtung bezieht sich die Integrationsmethode sowohl auf die horizontale als auch auf die vertikale Integration. Im Vordergrund steht ferner die zwischenbetriebliche Integration. Hinweise für eine Methode zur innerbetrieblichen Integration finden sich hingegen nicht. Strukturelle Charakteristika werden vor allem in Form des enthaltenen Vorgehensmodells sowie rudimentär in Form der sich daraus ergebenen Ergebnisdokumente thematisiert. Konkrete Techniken, Rollen sowie ein Metamodell sind hingegen nicht im Beitrag enthalten.

Unternehmensführung und Informationssystem: Der Ansatz des St. Galler Informationssystem-Managements (St. Galler ISM)265 Das St. Galler ISM entstand mit dem Ziel “…ein allgemeingültiges, praktisch anwendbares Vorgehensmodell für die Umsetzung von InformationssystemArchitekturen in Großunternehmen zu entwickeln.“266 Dazu wurde ein fünf Ebenen umfassendes Modell entwickelt. An oberster Stelle ist dabei das übergeordnete (1) „IS-Konzept“ eines Unternehmens angesiedelt. Dieses bezieht sich auf die darunter liegende (2) „IS-Architektur“ innerhalb der ebenfalls die Integrationsbereiche liegen. Auf der weiteren Ebene folgt das (3) „IS-Projektportfolio“ mit dem sich alle Informationssysteme betreffenden Projekte eines Unternehmens bewerten lassen. Organisatorische Lösungen, Applikationen und Datenbanken eines einzelnen Projekts finden sich auf der darunter liegenden Ebene (4) „IS-Projekt“. Auf unterster Ebene ist

265 266

Vgl. im Folgenden Österle et al. (1991); Hilbers (1992). Österle et al. (1991), S. 33.

88

Untersuchung bestehender Integrationsmethoden

schließlich die „IS-Betreuung“ angesiedelt, innerhalb derer Funktionen wie Support, Schulung oder Änderungsmanagement im Fokus stehen. Die folgenden Ausführungen beziehen sich im Kern auf die Ebene „IS-Architektur“, deren wesentlicher Bestandteil aus Planung, Verabschiedung, Umsetzung und Kontrolle von Integrationsbereichen besteht. Im Hinblick auf inhaltliche Charakteristika werden beim St. Galler ISM Daten und Funktionen thematisiert. Somit kann auf eine mehrheitliche Übereinstimmung des Integrationsgegenstands geschlossen werden. Auch im Hinblick auf Richtung und Reichweite stimmt die Integration gemäß des St. Galler ISM mit dem in der vorliegenden Arbeit definierten Integrationsbegriff überein. So wird bei der Richtung die horizontale sowie die vertikale Integration thematisiert und bei der Reichweite die inner- sowie die zwischenbetriebliche Integration.267 Auch die strukturellen Charakteristika sind beim St. Galler ISM umfangreich beschrieben. So wird zum einen ausführlich auf Aktivitäten und Ergebnisdokumente eingegangen. Das Vorgehen ist dabei in Form eines Ablaufplans mit den jeweiligen Input- und Outputdokumenten in die Schritte „Planung“, „Verabschiedung“, „Umsetzung“ und „Kontrolle“ von Integrationsbereichen unterteilt.268 Zum anderen können Techniken, also konkrete Anweisungen zum Erhalt von Ergebnisdokumenten, etwa in Form von Checklisten, entnommen werden. Diese sind allerdings nicht in allen Phasen des Vorgehensmodells enthalten. Ferner wird im Rahmen der Erläuterung der organisatorischen Ausgestaltung umfangreich auf Akteure und ihre Rollen eingegangen. Es lässt sich kein vollständiges Metamodell innerhalb des Beitrags aus St. Gallen identifizieren. Enthalten ist allerdings ein Metamodell für die Organisations-, Funktions- und Datensicht innerhalb des St. Galler Informationssystemsmanagements.

Electronic Data Interchange: A Total Management Guide (Emmelhainz)269 Emmelhainz gibt in ihrem Beitrag einen umfassenden Überblick über EDI. Darunter wird der zwischenbetriebliche Austausch von Geschäftsdokumenten in einer strukturierten und durch Maschinen verarbeitbaren Form verstanden.270 Der Beitrag gliedert sich dazu in vier wesentliche Teile: Nach einer Einführung werden Standards spezieller Hard- und Software sowie Möglichkeiten zur Datenübertragung EDI-relevanter Bestandteile vorgestellt. Im Anschluss gibt Emmelhainz einen 13 Schritte umfassenden Methodenvorschlag für die Implementierung von EDI. 267 268 269 270

Vgl. Österle et al. (1991), S. 66-67. Vgl. Österle et al. (1991), S. 112-153. Vgl. im Folgenden Emmelhainz (1990). Vgl. Emmelhainz (1990), S. 4.

Bestehende Integrationsmethoden im Überblick

89

Der Methodenvorschlag von Emmelhainz befasst sich mit dem zwischenbetrieblichen Datenaustausch. Somit kann für den Integrationsgegenstand als Bestandteil der inhaltlichen Charakteristika keine vollständige Übereinstimmung festgestellt werden, da Funktions- und Programmintegration im Beitrag keine Berücksichtigung finden. Für die Integrationsrichtung lassen sich primär Anweisungen für die horizontale Integration identifizieren. Jedoch finden sich ebenfalls Anhaltspunkte für mögliche vertikale Integration im Beitrag. So ist beispielsweise auf die Verknüpfung von Planungs- und Bestellsystemen bei Just-in-Time-Produktionen verwiesen.271 Zusätzlich zu diesen Hinweisen zur vertikalen Integration thematisiert Emmelhainz neben der im Fokus stehenden zwischenbetrieblichen Integration auch die innerbetriebliche Integration mittels EDI. Strukturelle Charakteristika finden sich bei Emmelhainz in Form von 13 beschriebenen Aktivitäten. Ein Ergebnismodell ließ sich allerdings nicht vollständig für alle Aktivitäten identifizieren. Trotzdem sind in der Hälfte der Phasen Hinweise auf Ergebnisdokumente enthalten. Wenn auch nicht vollständig finden sich ebenfalls in den Phasen entsprechende Techniken zum Erhalt von Ergebnisdokumenten. Ausführlich geht Emmelhainz jedoch auf die Rollen von Akteuren bei der Umsetzung von EDIProjekten ein. Ein Metamodell findet sich im Beitrag schließlich nicht. In Abb. 3.1.2/1 sind die inhaltlichen und strukturellen Übereinstimmungen der skizzierten Integrationsmethoden zusammenfassend dargestellt.

271

Vgl. Emmelhainz (1990), S. 34.

Untersuchung bestehender Integrationsmethoden

Methode

Horizontal

Vertikal

Innerbetrieblich

Zwischenbetrieblich

Metamodell

Aktivitätenmodell

Ergebnismiodell

Techniken

Rollen

3

3

3

3

2

2

3

3

3

3

3

2

Holten

3

3

2

2

2

3

3

2

3

3

(2)

2

ARIS

3

3

3

3

2

3

2

3

3

3

3

(2)

MOVE

3

2

2

3

2

2

3

2

3

3

3

2

Richtung

Zusammenfassung

Programme

FORWIN

Reichweite

Funktionen Gegenstand

Strukturelle Charakteristika

Daten

Inhaltliche Charakteristika

Linthicum

3

3

3

(2)

(2)

3

3

2

3

(3)

(2)

2

Gassner

3

3

2

2

2

2

2

3

3

3

2

2

Stietz

3

2

2

3

3

3

3

2

3

(2)

(2)

3

Fischer

3

2

2

3

3

2

3

2

3

(2)

2

2

St. Galler ISM

3

3

2

3

3

3

3

(3)

3

3

3

3

Emmelhainz

3

2

2

3

(3)

(3)

3

2

3

(3)

(3)

3

= hohe Übereinstimmung 3 = enthalten 2 = nicht enthalten

= teilweise Übereinstimmung

Zusammenfassung

90

= geringe Übereinstimmung

() = bedingt

Abb. 3.1.2/1: Zusammenfassung der inhaltlichen und strukturellen Übereinstimmungen

Zusammenfassend lassen sich die nach den inhaltlichen und methodischen Charakteristika untersuchten Anätze in eine Vier-Felder-Matrix mit den Dimensionen (1) inhaltliche und (2) methodische Vollständigkeit übertragen. Dabei ist das Feld, bei dem beide Dimensionen gering ausgeprägt sind, als „keine Integrationsmethoden“ bezeichnet und beinhaltet Ansätze, die sowohl im Hinblick auf die inhaltliche als auch auf die methodische Vollständigkeit Lücken aufweisen. Das Feld, bei dem die inhaltliche Komponente stark, die methodische Komponente hingegen gering ausgeprägt ist, wird als „unechte Integrationsmethoden“ bezeichnet. Hier werden die Methoden eingeordnet, die zwar inhaltlich umfangreiche Aussagen enthalten, jedoch methodisch durch ihre Unvollständigkeit nicht ohne weitere Hilfe einsetzbar erscheinen. Das dritte Feld der Matrix, bei dem die inhaltliche Komponente gering, die methodische Vollständigkeit jedoch umfassend ausgeprägt ist, wird als „spezialisierte Integrationsmethoden“ betitelt. In dieses Feld sind Integrationsmethoden eingeordnet, die zwar methodisch umfangreich beschrieben sind, sich jedoch inhaltlich auf lediglich einen spezifischen Teil der Integration von Anwendungssystemen beziehen. Schließlich ist im letzten, als „vollständige Integrationsmethoden“ bezeichneten Feld sowohl

Bestehende Integrationsmethoden im Überblick

91

die inhaltliche als auch die methodische Vollständigkeit hoch ausgeprägt. Mithilfe dieser Methoden soll ein Großteil möglicher Integrationsprobleme behandelt werden. In Abb. 3.1.2/2 sind die vorgestellten Integrationsmethoden eingeordnet. Dabei fiel keine der untersuchten Methoden eindeutig in das Feld „keine Integrationsmethoden“. Die Methoden von Fischer, Holten, Stietz und Linthicum liegen hingegen im Feld der „unechten Integrationsmethoden“. Somit ist ihnen zwar eine inhaltliche Vollständigkeit im vorgestellten Sinn zuzuschreiben. Jedoch ist die Beschreibung des methodischen Vorgehens für einen tatsächlichen Einsatz der Methoden zu rudimentär. hoch St. Gallen

Linthicum Stietz

FORWIN

ARIS

Emmelhainz

inhaltliche Vollständigkeit

Fischer

Holten

MOVE

Gassner

gering gering

strukturelle Vollständigkeit

hoch

Abb. 3.1.2/2: Gegenüberstellung der Methoden

Im Vergleich dazu findet sich in den Ansätzen von MOVE und Gassner eine relative hohe methodische Vollständigkeit. Jedoch sind diese Methoden lediglich auf bestimmte Teilbereiche möglicher Integrationsprojekte spezialisiert, was sich aus der geringen inhaltlichen Vollständigkeit ablesen lässt. Die Methoden von Emmelhainz, ARIS, FORWIN und St. Gallen eignen sich zum Einsatz bei einer Vielzahl von Integrationsproblemen. Des Weiteren beinhalten diese Ansätze vor allem im Vergleich zu den anderen untersuchten Methoden die am stärksten ausgeprägten methodischen Hinweise. Folglich eignen sich diese Methoden am ehesten für den tatsächlichen Einsatz im Rahmen von Integrationsprojekten. Für die vertiefende Analyse werden im Folgenden die Methoden herangezogen, bei denen sowohl die inhaltlichen als auch die strukturellen Charakteristika mindestens teilweise übereinstimmten. Den anderen Methoden wird entsprechend eine geringere Relevanz zugeschrieben. Dies lässt sich damit begründen, dass die Analyse von Methoden mit lückenhaften Hinweisen auf das methodische Vorgehen für einen Einsatz

92

Untersuchung bestehender Integrationsmethoden

in der Praxis kaum geeignet erscheint. Ferner ist die Aneignung von zwar methodisch vollständigen, jedoch inhaltlich spezialisierten Integrationsmethoden für etwaige unterschiedliche Integrationsprobleme aufgrund des entstehenden Aufwands bei der Aneignung einer Vielzahl von spezialisierten Methoden im unternehmerischen Alltag wenig praktikabel. Gemäß diesen Überlegungen sowie der vorangestellten inhaltlichen und methodischen Auswertung und Gegenüberstellung der Methode werden für die folgende Analyse lediglich die Methoden untersucht, die in das vierte, als „vollständige Integrationsmethoden“ betitelte Feld fallen. 3.2

Detaillierte Analyse ausgewählter Integrationsmethoden

Aus der in Kapitel 3.1.2 vorgenommenen übersichtsartigen Darstellung von Methoden zur Integration von Anwendungssystemen zeigten sich innerhalb dieser wesentliche Unterschiede. Sie wurden vor allem im Hinblick auf das zugrunde liegende Integrationsverständnis sowie auf die methodische Ausarbeitung identifiziert. Die Integrationsmethoden, die sich zum einen im Hinblick auf das Integrationsverständnis gleichen und bei denen zum anderen eine ausführliche methodische Beschreibung zugrunde liegt, sollen im Folgenden einer vertiefende Analyse unterzogen werden. Wie bereits beschrieben lassen sich einige strukturelle Komponenten der im Anschluss vorgestellten Integrationsmethoden nicht identifizieren. Im Falle von Techniken, Aktivitäten, Ergebnisdokumenten sowie Rollen wird im Laufe der Analyse darauf hingewiesen. Fehlende Metamodelle werden hingegen selbständig erstellt, soweit dies die Methodenbeschreibung zulässt. 3.2.1 FORWIN-Ansatz272 Wie in Kapitel 3.1.2 beschrieben, zielt die FORWIN-Methode insbesondere auf die zwischenbetriebliche Integration von Anwendungssystemen ab. Dazu wird eine Systematisierung anhand von sechs Ebenen vorgeschlagen. Ausgehend vom Geschäftsprozess (Ebene 1) werden die zu integrierenden Anwendungssysteme sowie die nötigen Funktionen des Integrationsmechanismus (Ebene 2 und 3) ermittelt. Auf den Ebenen 4 bis 6 erfolgt schließlich die Systematisierung des Integrationsmechanismus sowie die Implementierung. Zusätzlich zum Ebenenmodell beinhaltet die Methode ein neun Phasen umfassendes Vorgehensmodell.

272

Vgl. im Folgenden Mantel et al. (2004), S. 21-39; Eckert et al. (2004), S. 41-59.

Detaillierte Analyse ausgewählter Integrationsmethoden

93

Metamodell Den Ausgangspunkt des Metamodells stellen zwischenbetriebliche Geschäftsprozesse dar. Diese beinhalten Aufgaben, die aus einzelnen betrieblichen Objekten bestehen. Die Anwendungssysteme führen zu automatisierende Aufgaben der betrieblichen Objekte aus. Integrationsbereiche zwischen diesen Anwendungssystemen werden durch die Untersuchung der Aufgaben eines Prozesses und zwischen ihnen verlaufenden Transaktionen in Form von Aufgaben-Integrationsmustern (AIM) erfasst.273 Anhand drei unterschiedlicher AIM-Typen wird die zu entwickelnde Kopplungsarchitektur bestimmt (Daten-, Funktions-, oder Programmintegration) und deren Funktionalität mittels Funktionskomponenten definiert. Die Realisierung der Funktionen der Funktionskomponenten erfolgt durch zu erstellende Subsysteme innerhalb der Kopplungsarchitektur. Sie bieten – entsprechend der Funktion, die sie unterstützen – Dienste an und kommunizieren über Nachrichten mit anderen Subsystemen. Gesteuert werden die Subsysteme mithilfe von Prozessen (vgl. Abb. 3.2.1/1). unterteilt durch

besteht aus

betriebliches Objekt

Anwendungssystem

verbunden durch

Kopplungssystem beinhaltet

definiert

koordiniert

verbunden mit

bestimmt

Funktionskomponenten

Aufgabenintegrations-Muster

führt zu

betriebliche Transaktion

realisiert durch

agiert mit

zwischenbetr. Geschäftsprozess

automatisiert durch

Aufgabe

verbunden mit Prozess

Leistung

Subsystem tauscht / verarbeitet

steuert bestimmt

Nachricht

Abb. 3.2.1/1: Metamodell der FORWIN-Integrationsmethode

273

Vgl. Mantel et al. (2002), S. 194-195.

94

Untersuchung bestehender Integrationsmethoden

Vorgehens- und Ergebnismodell Das Vorgehen der FORWIN-Integrationsmethode ist in neun Phasen unterteilt.274 In der ersten Phase steht die Modellierung des zwischenbetrieblichen Geschäftsprozesses im Vordergrund. Durch eine schrittweise Verfeinerung sollen die betrieblichen Objekte sowie Transaktionen identifiziert werden. Dazu werden das Interaktionschema (IAS) sowie das Vorgangsereignisschema (VES) zur Spezifizierung der Objekte und des Prozessablaufs erstellt. Anhand dieser Ergebnisse können in der zweiten Phase die von der Integration betroffenen Anwendungssystemkerne ermittelt werden. Dazu werden die Objekte des Geschäftsprozesses und zwischen ihnen ablaufende Transaktionen gemäß ihrem Automatisierungsgrad strukturiert sowie die automatisierten Aufgaben den Anwendungssystemkernen zugeordnet. In der dritten Phase werden die Integrationsbereiche durch die Ermittlung von Aufgaben und ihre entsprechenden Transaktionsbeziehungen in Form von AIM abgegrenzt. Anhand dieser lässt sich die entsprechende Integrationsarchitektur zur Daten-, Funktions- oder Programmintegration ableiten. Nicht-funktionale Anforderungen der Integrationsarchitektur wie Flexibilität, Korrektheit, Echtzeitverhalten und Integration der Integrationsarchitektur werden im Anschluss in der vierten Phase spezifiziert.275 Infolgedessen wird in der fünften Phase der genaue Funktionsumfang der Integrationsarchitektur mithilfe eines Funktionskomponentenmodells definiert. Daraufhin kann in der sechsten Phase die Auswahl eines geeigneten Integrationsmechanismus erfolgen. Die Integration durch die Übertragung von Nachrichten und Diensten wird schließlich gemäß FORWIN durch Subsysteme realisiert. Diese werden in der siebten Phase erstellt. Die erstellten Subsysteme werden ferner gemäß der Anforderung einer eventuell nötigen parallelen Ausführung in der achten Phase in Form eines Prozessmodells den entsprechenden Prozessen zugeordnet. Damit lassen sich Anforderungen an den Integrationsmechanismus wie Skalierbarkeit, Verfügbarkeit und Performance berücksichtigen. Abschließend erfolgt in der neunten Phase die Implementierung.

Techniken Innerhalb der FORWIN-Integrationsmethode wird in der ersten, dritten und vierten Phase vertieft auf Techniken eingegangen.

274 275

Vgl. Mantel et al. (2004), S. 31-39 Vgl. Schissler et al. (2004), S. 12-13.

Detaillierte Analyse ausgewählter Integrationsmethoden

95

Zur Ermittlung des Geschäftsprozesses bzw. der betrieblichen Objekte und Transaktionen wird ein Vorgehen anhand des „Semantischen Objektmodells“ (SOM) vorgeschlagen:276 Ein Geschäftsprozess kann demnach mittels eines drei Ebenen und zwei Sichten umfassenden Vorgehensmodells erfasst werden. Darin ist das Vorgehen mithilfe des zu ermittelnden Interaktions- (IAS) und Vorgangsereignisschemas (VES) enthalten. Das IAS erfasst dabei die vom Geschäftsprozess erstellten Leistungen (Leistungsschicht) sowie die dazu nötigen Objekte und Transaktionen (Lenkungsschicht). Das VES hingegen stellt den ereignisgesteuerten Ablauf eines Geschäftprozesses (Ablaufsicht) dar. Ausgehend von einem groben IAS und VES können mithilfe der Objekt- und Transaktionszerlegung die Schemata im Detail ermittelt werden. Als weitere Technik wird in der vierten Phase die Erstellung von Aufgabenintegrationsmustern (AIM) vorgeschlagen. Diese dienen der Abgrenzung und Systematisierung von Integrationsbereichen eines Anwendungssystems. In einem AIM werden die Beziehungen zwischen Aufgaben und Transaktionen eines Geschäftsobjekts erfasst.277 Daraus lässt sich im Anschluss die Variante der Integrationsarchitektur ermitteln (Daten-, Funktions- oder Programmintegration). Drei elementare AIMs lassen sich für die Zuordnung unterschieden. Bei (1) Reihenfolgebeziehungen zwischen Aufgabendurchführungen wird eine Verrichtung im empfangenden betrieblichen Objekt von einer Transaktion angestoßen. Aufgaben und Transaktionen dieser AIMs werden gemäß der Programmintegration integriert. Eine (2) gemeinsame Nutzung von Aufgabenobjekt-Instanzen liegt hingegen vor, wenn verschiedene, durch Transaktionen verknüpfte betriebliche Objekte die gleichen Daten nutzen. Somit führen diese AIMs zur Datenintegration. Schließlich wird die (3) gemeinsame Nutzung von Lösungsverfahren aufgeführt, wenn Aufgaben der Anwendungssysteme die gleichen Lösungsverfahren verwenden. Diese AIMs führen schließlich zur Funktionsintegration. Die Erfassung der nicht-funktionalen Anforderungen der vierten Phase kann mittels eines vier Kategorien umfassenden Katalogs gemäß ISO-Norm 9126-1 erfolgen.278 Diese Kategorien beinhalten die Flexibilität, das Echtzeitverhalten, die Integration sowie die Korrektheit:279 Die (1) Flexibilität bezieht sich auf die Skalierbarkeit sowie Anpassbarkeit des Integrationsmechanismus. Thematisiert wird dabei ein möglicher Einbezug weiterer Anwendungssysteme in den Kopplungsmechanismus.

276 277 278 279

Vgl. hierzu und im Folgenden Ferstl/Sinz (2001), S. 180-213. Vgl. Mantel et al. (2004), S. 194-195. Vgl. Schissler et al. (2004), S. 12-13. Vgl. Ferstl (1992), S. 11-12.

96

Untersuchung bestehender Integrationsmethoden

Mittels des (2) Echtzeitverhaltens werden Verfügbarkeits-, Last- sowie Aktualitätsanforderungen erfasst und somit die Performance-Anforderungen des Kopplungsmechanismus ermittelt. Des Weiteren dient die Kategorie (3) Integration der Erfassung von Redundanzen (etwa von Daten) und dem Verknüpfungsgrad des Kopplungsmechanismus. Schließlich wird mittels der Kategorie (4) Korrektheit die Anforderung im Hinblick auf die Eindeutigkeit, Widerspruchsfreiheit sowie Vollständigkeit der Aufgabendurchführung im Integrationsmechanismus erfasst.

Rollenmodell In der FORWIN-Integrationsmethode sind keine Hinweise auf Akteure und Rollen enthalten. Daher lässt sich aus der Integrationsmethode kein Rollenmodell ableiten. 3.2.2 ARIS-Ansatz Die Architektur integrierter Informationssysteme (ARIS) eignet sich für die Entwicklung integrierter Anwendungssystemen, den Einsatz von integrierter Standardsoftware sowie die Montage von Softwarebausteinen zu großintegrierten Anwendungssystemen. Innerhalb der Architektur werden fünf voneinander getrennte Sichten unterschieden: Die Funktionssicht ist für die Funktionalität und die Datensicht für die Datenhaltung des Anwendungssystems zuständig. Mittels der Organisationssicht wird die Aufbauorganisation der vom System betroffenen Organisationseinheiten abgebildet. Innerhalb der Leistungssicht sind schließlich alle Input- und Outputleistungen des zugrunde liegenden Geschäftsprozesses erfasst. Schließlich werden mithilfe der Steuerungssicht die ansonsten voneinander getrennten Sichten koordiniert. Die ARIS-Architektur ist gemäß dem klassischen Vorgehen in der Softwareentwicklung in die Phasen Fachkonzept, DV-Konzept sowie Implementierung unterteilt (vgl. Abb. 3.2.2/1).

Detaillierte Analyse ausgewählter Integrationsmethoden

97

Organisationssicht Fachkonzept DV-Konzept Implementierung

Fachkonzept

Fachkonzept

Fachkonzept

DV-Konzept

DV-Konzept

DV-Konzept

Implementierung

Implementierung

Implementierung

Datensicht

Steuerungssicht

Funktionssicht

Fachkonzept DV-Konzept Implementierung Leistungssicht

Abb. 3.2.2/1: ARIS-Architektur280

Metamodell Das zentrale Element des ARIS-Metamodells stellt der Geschäftprozess dar, dessen Grundlage die Unternehmensstrategie bildet. Ausgeführt wird er von einer Organisationseinheit. Die Workflowsteuerung eines integrierten Anwendungssystems koordiniert den Prozess, indem sie die Weiterleitung der Informationsobjekte übernimmt. Die Extraktion und Übergabe der Informationsobjekte erfolgt über Schnittstellen mittels derer auf weitere Anwendungssysteme zurückgegriffen wird. Die im Anwendungssystem enthaltenen Funktionen bearbeiten die von den Schnittstellen bereitgestellten Informationsobjekte. Das Ergebnis bilden Leistungen, etwa in Form von einer Bestellung, einem Kunden- oder Versandauftrag (vgl. Abb. 3.2.2/2).

280

In Anlehnung Scheer (1991), S. 18.

98

Untersuchung bestehender Integrationsmethoden

erzeugt

hat

ist zugeordnet

nutzt

Organisationseinheit

koordiniert

Anwendungssystem

verwendet

Schnittstelle

Funktion löst aus

bestimmt

Workflowsteuerung

Leistung

ist Input / Output

führt aus

steuert

Geschäftsprozess

Unternehmen hat

gestaltet

Strategie

verknüpft

verwendet überträgt

Informationsobjekt

Abb. 3.2.2/2: ARIS-Metamodell

Vorgehens- und Ergebnismodell Das ARIS-Vorgehensmodell ist in vier Phasen unterteilt. Zu Projektbeginn wird in der ersten Phase eine Vorgangskettenanalyse vorgenmommen. Diese beinhaltet eine detaillierte Prozessbeschreibung, die der Erfassung der Ausgangssituation und Projektziele, der Schwachstellen der gegenwärtigen Lösung sowie der Inhalte des Soll-Konzepts dient. Im Anschluss an diese Beschreibung werden in der zweiten Phase parallel die Fachkonzepte für die weiteren Sichten der ARIS-Architektur erstellt. Darin enthalten ist die Erstellung der Fachkonzepte für die Funktions-, Organisations-, Daten-, Leistungsund Steuerungssicht: Die Funktionssicht dient der Erfassung der Zusammenhänge innerhalb der Vorgangsketten. Mittels der Organisationssicht lassen sich die spezifischen Organisationseinheiten für die Zuständigkeiten und Verantwortungen bezüglich der Funktionen und Daten ermitteln. Für die Datensicht, als wichtigster Baustein der ARIS-Architektur, sind die Start- und Ergebnisereignisse einer spezifischen Vorgangskette sowie die Zustandbeschreibung des relevanten Umfelds zu spezifizieren. Das Fachkonzept der Leistungssicht beschreibt die nötigen In- und Outputs. Die erarbeite Steuerungssicht stellt schließlich die Zusammenhänge zwischen den zuvor einzeln erfassten Sichten her. Nach Abschluss der Fachkonzepte sind in der dritten Phase die DV-Konzepte sämtlicher Sichten zu erstellen: Dabei erfolgt zunächst die Ermittlung der zu entwickelnden

Detaillierte Analyse ausgewählter Integrationsmethoden

99

Modulkomponenten, Kontrollstrukturen und Ausgabepräsentation. Innerhalb des DVKonzepts der Organisationssicht wird weiterhin das fachliche Organisationsmodell an das Anwendungssystem angepasst. Dazu müssen Kapazitäten, Zugangsberechtigungen sowie eine dem jeweiligen Anwender zugeordnete IT-Infrastruktur festgelegt werden. Im DV-Konzept der Datensicht ist ferner das Datenmodell des Fachkonzepts in die Sprache der Schnittstellen und Datenbanksysteme umzusetzen. Schließlich erfolgt bei der Erstellung des DV-Konzepts der Steuerungssicht die Zusammenführung der bisher separat betrachteten Beziehungen zwischen den einzelnen Sichten. In der vierten Phase findet die Implementierung der einzelnen Sichten statt. Dabei werden die in der vorherigen Phase erstellten DV-Konzepte in ausführbare Systeme umgesetzt und an die Spezifikationen der IT-Infrastruktur angepasst. Das DVKonzept der Funktionssicht ist dabei in Form eines konkreten Anwendungsprogramms zu überführen. Für die Implementierung der Organisationssicht wird die im DV-Konzept definierte IT-Infrastruktur berücksichtigt. Dazu zählt ebenfalls die physische Verbindung der Anwendungssysteme bzw. der Hardware, auf denen diese laufen. Die Implementierung der Datensicht umfasst die Erstellung einer der Vorgangskette zugrunde liegenden Datenbank. Schließlich werden bei der Implementierung der Steuerungssicht wiederum die zuvor einzeln implementierten Sichten miteinander verbunden. Da die Leistungssicht nicht in Form eines Anwendungssystems implementiert wird, bedarf es nicht der Erstellung eines entsprechenden DV-Konzepts und der Implementierung. Die Ergebnisdokumente resultieren im Wesentlichen aus den ersten drei Phasen des ARIS-Vorgehensmodells. Ist- und Soll-Vorgangskette bilden entsprechend das Ergebnis der Vorgangskettenanalyse in der ersten Phase. Die zweite Phase endet mit den Fachkonzepten der jeweiligen Schichten. Das Fachkonzept wird aus der semantischen Ausgangssituation in Form der Vorgangskettenbeschreibung abgeleitet und ist selbst Ausgangspunkt für die spätere Umsetzung des integrierten Anwendungssystems. In vergleichbarer Weise schließt die dritte Phase mit dem DV-Konzept der Schichten ab. Es stellt die Verbindung zwischen dem fachlichen Entwurf des integrierten Anwendungssystems und der Implementierung dar. Somit ist das DV-Konzept stärker formalisiert als das Fachkonzept. Zusätzlich werden für das DV-Konzept informationstechnische Anforderungen wie die Performance, Vermeidung von Redundanzen und Anomalien berücksichtigt. Zur Mehrfachnutzung von bereits entwickelten Anwendungsmodulen wird in der vierten Phase eine Programmbibliothek angelegt, die diese Module enthält.

100

Untersuchung bestehender Integrationsmethoden

Techniken Innerhalb der ARIS-Integrationsmethode sind unterschiedliche Techniken beschrieben bzw. es wird auf selbige hingewiesen. Der Detaillierungsgrad der Beschreibung schwankt allerdings mitunter. Ein starker Fokus des ARIS-Ansatzes liegt auf Modellierungstechniken, welche die Spezifikation des integrierten Anwendungssystems unterstützen. Die Techniken sind innerhalb der Phasen den jeweiligen Sichten der ARISArchitektur zugeordnet. Ausgenommen davon sind die Techniken der ersten Phase, da in der noch keine Trennung der Sichten vorgenommen ist. Die Techniken der ersten Phase dienen der möglichst geschlossenen Erfassung der entsprechenden Vorgangskette unter der Berücksichtigung von Vorgängen, Organisationseinheiten sowie Anwendungssystemen. Das halbformale Verfahren der Vorgangskettenanalyse lässt dabei die Erfassung um bestehende Medienbrüche aufzudecken. Neben der Erfassung des Ist-Zustandes ist mithilfe der Vorgangskettendiagramme ebenso der Soll-Zustand zu beschreiben. Die Techniken der zweiten Phase dienen dem fachlichen Entwurf der Funktions-, Organisations-, Leistungs- und Steuerungssicht. Die Techniken der Funktionssicht zielen dabei auf die Erfassung der relevanten Vorgänge ab, während die Techniken der Organisationssicht die Organisationsstruktur sowie die relevanten Nutzer ermittelt. Ferner zielen die Techniken der Datensicht auf die Ermittlung der relevanten Daten des integrierten Anwendungssystems. Techniken der Leistungssicht widmen sich der Erfassung sämtlicher Leistungen, die durch den Geschäftsprozess entstehen sowie deren Zusammenhänge. Neben den Techniken zum Entwurf der einzelnen Sichten werden zusätzlich Techniken der Steuerungssicht vorgestellt. Diese sollen die Zusammenhänge zwischen den einzelnen Sichten aufdecken. Die Techniken der dritten Phase dienen der Vorbereitung der innerhalb des fachlichen Entwurfs enthaltenen Ergebnisse für die spätere Implementierung. Ähnlich wie bereits in der zweiten Phase werden zum einen die jeweiligen Sichten getrennt von einander spezifiziert. Zum anderen dienen die Techniken der Steuerungssicht im Anschluss daran dazu die Zusammenhänge der getrennt voneinander betrachteten Sichten herzustellen. Hinsichtlich der vierten Phase finden sich lediglich zwei Hinweise auf Techniken. Zum einen dienen diese der Zusammenfassung bereits realisierter Funktionen in Programmbibliotheken. Zum anderen soll für die Implementierung der Organisationssicht die Netztopologie der DV-Konzeption im Hinblick auf ihre logische bzw. physische Verknüpfung erweitert werden. Techniken für die weiteren Sichten finden sich nicht. Vielmehr wird auf die Umsetzung dieser Sichten anhand des DV-Konzepts mittels geeigneter Programmiersprachen hingewiesen.

Detaillierte Analyse ausgewählter Integrationsmethoden

101

Rollenmodell Ein ausgearbeitetes Rollenmodell für die Phasen der ARIS-Architektur ließ sich nicht identifizieren. Es finden sich lediglich vereinzelt Hinweise für Rollen. So wird zum einen auf die Mithilfe der Fachabteilung im Rahmen der Phase der Prozessbeschreibung hingewiesen. Zum anderen wird für die Umsetzung der Projekte die Bildung einer Referenzgruppe mit der Zuständigkeit für verschiedene Teilprojekte vorgeschlagen. 3.2.3 St. Galler Ansatz281 Der St. Galler Ansatz des Informationssystemmanagements ist in fünf Ebenen unterteilt. Diese umfassen das (1) IS-Konzept, die (2) Architektur, das (3) ISProjektportfolio, das (4) IS-Projekt sowie die (5) IS-Betreuung. Die Integration von Anwendungssystemen ist innerhalb des Ebenenmodells auf der zweiten Ebene (Architektur) verankert (vgl. Abb. 3.2.3/1).282 IS-Konzept

IS-Architektur

Planung, Verabschiedung, Umsetzung Kontrolle von Integrationsbereichen

IS-Projektportfolio

IS-Projekt

IS-Betreuung

Abb. 3.2.3/1: Ebene des St. Galler Informationssystemmanagements283

Metamodell Ausgangspunkt des Metamodells ist die Geschäftseinheit eines Unternehmens. Diese führt die Geschäftsfunktionen des Unternehmens durch und verfolgt dabei eine vorgegebene Unternehmensstrategie. Bei der Durchführung von Geschäftsfunktionen werden die Geschäftseinheiten von der Informationsverarbeitung (IV) in Form

281 282 283

Vgl. im Folgenden Österle et al. (1991), S. 111-153. Für einen Überblick über die Bedeutung der Ebenen vgl. Kapitel 3.1.2. In Anlehnung an Österle et al. (1991), S. 41.

102

Untersuchung bestehender Integrationsmethoden

von Applikationen unterstützt. Diese verwenden Datenbanken, in welchen die Geschäftsobjekte in Form von Daten gespeichert sind. Zwischen solchen Geschäftsfunktionen liegen Integrationsbereiche, die durch den Austausch von Geschäftsobjekten verbunden sind. Ihre tatsächliche Realisierung soll nur erfolgen, sofern deren jeweilige Integration die Strategie des Unternehmens unterstützt. Des Weiteren werden die Integrationsbereiche vor einer möglichen Realisierung anhand der den Geschäftsfunktionen zugeordneten Erfolgsfaktoren hinsichtlich entstehender Nutzeffekte und Kosten der Integration bewertet. Abhängig von der gewählten Umsetzungsvariante wird die Integration mithilfe von Applikationen oder Datenbanken realisiert. Das Metamodell der St. Galler Integrationsmethode ist in Abb. 3.2.3/2 dargestellt.

Datenbank

nutzt

nutzt / produziert

verwendet

Geschäftsfunktion

Applikation (IV)

bestimmt

Strategie

hat

Erfolgsfaktor

integriert

realisiert

unterstützt

enthält

Geschäftsobjekt (Datum)

unterstützt

verbunden mit

hat

ist zugeordnet

Geschäftseinheit

bewertet

verwendet

Integrationsbereich

realisiert

Abb. 3.2.3/2: Metamodell der St. Galler Integrationsmethode

Vorgehens- und Ergebnismodell Das Vorgehensmodell der Ebene Integrationsbereiche ist in vier Schritte unterteilt. Diese umfassen die (1) Planung, (2) Verabschiedung, (3) Umsetzung und (4) Kontrolle von Integrationsbereichen. Innerhalb der Schritte sind verschiedene Teilfunktionen zu realisieren. Planung von Integrationsbereichen Zur Identifizierung der Integrationsbereiche wird die Wertkettenanalyse vorgeschlagen. Von dieser ausgehend lassen sich Geschäftsfunktionen und ihre Zusammenhänge ableiten. Damit lässt sich die Informationsverarbeitung innerhalb (Input-

Detaillierte Analyse ausgewählter Integrationsmethoden

103

Process-Output) sowie zwischen (Datenfluss) den Geschäftsfunktionen erfassen. Mittels dabei aufgedeckter Interdependenzen sind im Anschluss Integrationsbereiche abzuleiten. Mit den Erfolgsfaktoren der Geschäftsfunktionen und anhand der Unternehmensstrategie sowie der bestehenden informationstechnischen Infrastruktur wird die Vorteilhaftigkeit des ermittelten Integrationsbereichs überprüft. Den Abschluss der Planung bildet die Formulierung eines Rahmenprojekts mit verschiedenen Einzelprojekten und Maßnahmen zur Realisierung der Integrationsbereiche. Verabschiedung von Integrationsbereichen Aus den identifizierten Integrationsbereichen der vorangestellten Phase werden von den betroffenen Fachbereichen in Zusammenarbeit mit deren dezentralen IS-Leitern Vorschläge von zu realisierenden Integrationsbereichen abgeleitet. Daraufhin sind die Vorschläge zu bewerten und zu verabschieden. Die Bewertung bezieht sich auf die Korrektheit der Planung, der Bewertung des Integrationsnutzens und der -kosten sowie auf die Übereinstimmung mit dem bestehenden Unternehmenskonzept. Das Ergebnis der Bewertung wird in einem Dokument publiziert, welches die Beschreibung der verabschiedeten Integrationsbereiche beinhaltet. Umsetzung von Integrationsbereichen Die Umsetzungsphase beginnt mit der Projektplanung (Projektierung) des Integrationsbereichs. Diese beinhaltet die benannten Einzelprojekte und Maßnahmen zur Realisierung, deren Terminierung sowie die Schätzung von Kosten und Nutzen. Im Anschluss wird der Integrationsbereich publiziert. Die Publikation dient der Überzeugung der betroffenen Unternehmenseinheiten, um die Realisierung erfolgreich durchzuführen. Zur ordnungsgemäßen Steuerung sind die ermittelten Einzelprojekte im Anschluss in das Projektportfolio des Unternehmens aufzunehmen. Die Übernahme der Projekte in das Projektportfolio löst eine Reihe von Tätigkeiten des Projektmanagements aus:284 Zur einheitlichen Bearbeitung der Projekte innerhalb des Projektportfolios sind zum einen standardisierte Informationssystem-Anträge zu erstellen. Des Weiteren wird für Projekte mit einer Laufzeit von mehr als zwei Jahren die Durchführung einer Machbarkeitsstudie aufgeführt. Diese beinhaltet etwa einen detaillierten Lösungsvorschlag, eine Wirtschaftlichkeits- und Risikoanalyse sowie den Entwurf der Projektorganisation. Schließlich sollen die positiv bewerteten Projekte in einem Informationssystem-Entwicklungsplan zusammengefasst werden. Innerhalb diesem werden die personellen und finanziellen Kapazitäten der Realisierung sowie die zeitliche Abfolge der Bearbeitung festgelegt. Die tatsächliche Realisierung beginnt mit der Konzeption des Integrationsbereichs. In Abhängigkeit von der gewählten Realisierungsmöglichkeit (Daten-, Funktions- und 284

Vgl. im Folgenden Österle et al. (1991), S. 206-238.

104

Untersuchung bestehender Integrationsmethoden

Schnittstellenintegration) erfolgt die Ermittlung der gewünschten InformationssystemArchitektur.285 Darin enthalten ist die Entwicklung des Organisations-, Funktions-, Daten- und Kommunikationsmodells. Des Weiteren sind die Anforderungen an die Sicherheit der Daten und Funktionen auszuarbeiten, ebenso wie weitere Anforderungen an die technische Infrastruktur. Durch so genannte „Maßnahmen“ und Einzelprojekte erfolgt die Umsetzung des Integrationsbereichs gemäß der erstellten Architektur.286 Nach einer Vorstudie ist dafür das Lösungskonzept zu erarbeiten. Dieses spezifiziert zunächst die zu erstellende Architektur (als proprietäre Entwicklung oder Standardlösung sowie ob zentrale oder dezentrale). Im Anschluss erfolgen Detailspezifikation, Programmierung, Datenbereitstellung sowie die Erarbeitung der zukünftigen Nutzerorganisation. Zum Abschluss der Umsetzung erfolgen Systemtests sowie die Einführung des Integrationsmechanismus. Kontrolle von Integrationsbereichen Die Kontrolle von Integrationsbereichen bildet entsprechend dem St. Galler Informationsmanagement die letzte Phase. Dabei sind der Projekt- und der zentrale ISAusschuss in regelmäßigen Abständen über den Stand des Projekts zu informieren. Die Ausschüsse entscheiden daraufhin über die Anpassung der Ziele, Reichweite, Kosten oder Terminierung des Integrationsprojekts. Bedarf es Änderungen am Integrationsbereich, so werden entsprechende Projekte grundsätzlich in einem ähnlichen Vorgehen durchgeführt, wie die zuvor beschriebenen umfangreichen Informationssystem-Projekte.287 Dazu sind die Änderungen in einem ersten Schritt zu sammeln und zu bewerten. Nachfolgend lässt sich die Realisierung von positiv bewerteten Änderungsanträgen planen, so dass schließlich die tatsächliche Umsetzung sowie Kontrolle erfolgen kann.

Techniken Innerhalb der St. Galler Integrationsmethode werden nur für einige Phasen Techniken aufgeführt bzw. auf selbige verwiesen. Die enthaltenen Techniken werden im Folgenden den Phasen zugeordnet und vorgestellt: In der ersten Phase (Planung) wird zur Ermittlung von Integrationsbereichen auf die Wertkettenanalyse nach Porter verwiesen. Diese dient der Identifizierung von Geschäftsfunktionen zwischen denen die Integrationsbereiche liegen. Zusätzlich werden

285 286 287

Vgl. Österle et al. (1991), S. 154-170. Vgl. Österle et al. (1991), S. 284-293. Vgl. Österle et al. (1991), S. 295-312.

Detaillierte Analyse ausgewählter Integrationsmethoden

105

die Erstellung von Datenflussplänen oder grafisch dargestellten Ablauffolgen und Matrizen zur Identifikation der Integrationsbereiche genannt. Zur Unterstützung der zweiten Phase (Verabschiedung von Integrationsbereichen) enthält die Integrationsmethode unterschiedliche Checklisten. Mithilfe dieser lässt sich die Planung, der ermittelte Integrationsnutzen und die -kosten im Hinblick auf ihre Richtigkeit bewerten sowie die Abstimmung der vorgeschlagenen Integrationsbereiche gemäß des Unternehmenskonzepts vornehmen. Die dritte Phase (Umsetzung) beinhaltet eine Technik zur Ermittlung von Umsetzungsvarianten von Integrationsbereichen.288 Mittels einer Matrix lassen sich dabei Hinweise auf die zu wählende Integrationsvariante (Daten-, Funktions- oder Programmintegration) ableiten. Dazu sind gemäß der Matrix die angestrebten Integrationsobjekte (Daten, Funktionen und Schnittstellen) als erste Dimension sowie hinsichtlich der zweiten Dimension das jeweilige Integrationsziel (Mehrfachverwendung im Gegensatz zur gemeinsamen Nutzung) zu erfassen. Des Weiteren wird in der dritten Phase auf Techniken des Projektmanagements, wie Projektplan, Organigramm und Checklisten eingegangen, welche die Steuerung der Umsetzung ermöglichen. Schließlich ist für die vierte Phase (Kontrolle) eine Checkliste zur Unterstützung der Ermittlung des Status der Umsetzung enthalten.

Rollenmodell Das Rollenmodell der St. Galler Integrationsmethode umfasst sechs Rollen mit unterschiedlichen Aufgaben innerhalb der Phasen des Vorgehensmodells (vgl. Abb. 3.2.3/3).

288

Vgl. Hilbers (1992), S. 164.

106

Untersuchung bestehender Integrationsmethoden

Rolle

Phase

IS-Ausschuss (zentral)

Beschreibung

Verabschiedung

Bewertung und Bechluss von Integrationsbereichen

Planung

Planung von Integrationsbereichen

Kontrolle

Kontrolle der Projektarbeit zu Integrationsbereichen

Planung

Planung von Integrationsbereichen

Umsetzung

Dokumentation und Pflege von Integrationsbereichen

IS-Leiter (zentral)

Architektur-Entwicklung (zentral)

Projektleiter (dezentral)

Projektausschuss zum Integrationsbereich (dezentral)

Kontrolle

Kontrolle der Projektarbeit zu Integrationsbereichen

Umsetzung

Publikation des Integrationsbereichs

Umsetzung

Übergabe von Architekturteilen an Architekturentwicklung

Kontrolle

Erstellt Statusbericht für IS-Ausschuss

Umsetzung

Umsetzung von Integrationsbereichen

Kontrolle

Kontrolle von Integrationsbereichen

Planung

Diskussion von Integrationsbereichen

Umsetzung

Projektsteuerung zur Umsetzung von Integrationsbereichen

Umsetzung

Projektsteuerung zur Umsetzung von Integrationsbereichen

IS-Leiter (dezentral)

IS-Ausschuss (dezentral)

Abb. 3.2.3/3: Rollenmodell der St. Galler Integrationsmethode

Innerhalb des Rollenmodells steht die Unterscheidung von zentralen und dezentralen Rollen im Fokus. Zentral sind insbesondere solche Rollen, die im Zusammenhang mit der Identifikation, Bewertung, Verabschiedung sowie mit der Kontrolle von Integrationsbereichen beauftragt sind. Hingegen sind Akteure mit dezentralen Rollen im Vergleich dazu vielmehr für die Umsetzung des Integrationsbereichs sowie für die operative Projektsteuerung verantwortlich. 3.2.4 Emmelhainz-Ansatz289 Die Integration von Anwendungssystemen wird im Beitrag von Emmelhainz mithilfe des automatischen Austauschs von strukturierten Geschäftsnachrichten, Electronic Data Interchange (EDI), vollzogen. Dazu ist im Beitrag ein 13 Schritte umfassendes Vorgehensmodell enthalten. Dieses soll vor allem bei der Entscheidung des EDIEinsatzes unterstützen sowie bei der Auswahl von EDI-Varianten und der EDIEinführung Hilfestellung bieten.

289

Vgl. im Folgenden Emmelhainz (1990), S. 125-191.

Detaillierte Analyse ausgewählter Integrationsmethoden

107

Metamodell Das Metamodell der Integrationsmethode nach Emmelhainz beinhaltet mit der EDIImplementierung und dem EDI-System zwei zentrale Punkte (vgl. Abb. 3.2.4/1). führt aus

bemisst

EDI-Implementierung

Transaktion

EDIStandards

EDI-Grad

unterstützt Management

Geschäftspartner

beinhaltet

Daten

verarabeitet

bestimmt

definiert

gibt vor

bestimmt

bestimmt

EDIStrategie

führt zu

EDI-System

verbindet

ist verbunden mit

Informationssystem

Abb. 3.2.4/1: Metamodell der Integrationsmethode nach Emmelhainz

Die EDI-Implementierung wird durch die vom Management und den Geschäftspartnern vorgegebene EDI-Strategie bestimmt. Im Kern bemisst die Strategie den Grad der Implementierung. Die EDI-Implementierung führt zum EDI-System, das die zweite wesentliche Komponente des Metamodells darstellt. Das EDI-System dient der Integration von Informationssystemen, die wiederum für die Verarbeitung der Daten zuständig sind. Daten sind Bestandteile der Transaktionen, die mit einem Geschäftspartner durchgeführt werden. Mittels der vom EDI-System vorgegebenen EDIStandards werden die in einer Transaktion beinhalteten Daten den beteiligten Informationssystemen entsprechend definiert.

Vorgehens- und Ergebnismodell Im Beitrag von Emmelhainz wird ein 13 Phasen umfassendes Vorgehensmodell vorgestellt. Zu Beginn steht dabei in der ersten Phase die Entscheidung über die entsprechende EDI-Strategie eines Unternehmens an. Diese ist von verschiedenen Faktoren abhängig, wie den zur Verfügung stehenden Ressourcen, den Interessen der Geschäftspartner sowie der Unternehmensführung. Insgesamt kann eine unterschiedliche Implementierungsintensität unterschieden werden. Diese ergibt sich zum einen aus der Höhe mittels EDI verknüpfter Transaktionen und Geschäftspartner. Zum anderen aus der Anbindung der internen Anwendungssysteme an die EDISchnittstelle und dem Umfang ihrer internen Verknüpfung. Dementsprechend können drei Grade der Implementierungsintensität unterschieden werden. Beim geringsten Grad wird EDI in einem Unternehmen lediglich von einem Unternehmensbereich für eine einzige Transaktion mit wenigen Geschäftspartnern genutzt. Beim nächst höheren Grad wird EDI ferner von vielen Bereichen für eine Vielzahl von Transaktionen

108

Untersuchung bestehender Integrationsmethoden

und Geschäftspartnern eingesetzt. Schließlich wird beim höchsten Grad eine EDIImplementierung für das gesamte Unternehmen angestrebt. Die Anwendungssysteme des betroffenen Unternehmens sind dabei umfangreich miteinander verbunden und die EDI-Implementierung soll ebenfalls weitgehend die Geschäftspartner einbeziehen. In der zweiten Phase soll im Anschluss die Unterstützung des Top-Managements für die EDI-Implementierung eingeholt werden. Die Bedeutung der Unterstützung des Managements wird dabei anhand der bei einer EDI-Implementierung nötigen Koordination zwischen verschiedenen Unternehmensbereichen sowie der hohen Implementierungsaufwendungen besonders hervorgehoben. In der dritten Phase findet die Bildung des EDI-Projektteams statt. Dieses soll möglichst aus Mitarbeitern aller von der EDI-Implementierung betroffenen Bereiche zusammengesetzt werden. Zusätzlich bedarf es der Bestimmung eines geeigneten Teamleiters. Dieser sollte ein möglichst breites Geschäftsverständnis besitzen sowie ein Befürworter des EDI-Einsatzes sein. In der vierten Phase erfolgt die Schulung der Mitarbeiter des Unternehmens sowie der betroffenen Geschäftspartner hinsichtlich EDI und dessen Funktionsweise. Verwendet werden sollen dazu vorhandene Quellen von Branchenverbänden, Standardkomitees sowie EDI-Anbietern. In der fünften Phase ist der derzeitige typischerweise manuelle und papiergetriebene Informationsfluss sowie die entsprechende Datenstruktur der betroffenen Anwendungssysteme zu analysieren. Daraufhin sind die nötigen Anpassungen für eine EDILösung zu erarbeiten, so dass schließlich Softwareentwicklung beginnen kann. In der sechsten Phase erfolgt eine wirtschaftliche Bewertung der EDI-Lösung. Dabei sind Kosten für die Implementierung und Nutzung sowie direkte (bspw. geringere Personal- und Lagerkosten) und indirekte Nutzeffekte (bspw. ein verbesserter Informationszugang) zu erfassen und gegenüberzustellen. Für die EDI-Implementierung soll in der siebten Phase über die konkrete Ausgestaltung der EDI-Lösung entschieden werden. Dabei sind Fragen im Hinblick auf die physische Verknüpfung der Anwendungssysteme (direkte Verbindung über Modem oder über Netzwerkanbieter), die Eigenentwicklung oder den Einsatz einer Standard EDI-Lösung, die Auswahl betroffener Transaktionen und Unternehmensbereiche sowie die Auswahl geeigneter Geschäftspartner von Belang. Im Anschluss erfolgt in der achten Phase die genaue Spezifikation der Daten, die mithilfe der EDI-Lösung ausgetauscht werden sollen. Dazu werden durch EDIStandards vorgegebene Spezifikationen an den konkreten Einsatz angepasst. Definiert werden dabei insbesondere die konkret auszutauschenden Transaktionsdaten,

Detaillierte Analyse ausgewählter Integrationsmethoden

109

die Handhabung zusätzlicher optionaler Daten, die Kennzeichnung von Produkten, Unternehmen, Versandstellen sowie die Auswahl des Kommunikationsprotokolls. Für die anstehende EDI-Nutzung wird in der neunten Phase die Festlegung der rechtlichen Rahmenbedingungen empfohlen. Davon sind zum einen die Transaktionspartner betroffen sowie zum anderen die Netzwerkanbieter und die Anbieter der EDI-Software. In der zehnten Phase wird der Test einer Vorabversion des EDI-Systems empfohlen. Dieser Test soll drei verschiedene Stufen umfassen. Auf der untersten Stufe sollen zur Sicherstellung der korrekten Verbindung, der Funktionstüchtigkeit der Software und der Möglichkeit des Datenaustauschs Test-Transaktionen vorgenommen werden. Auf der nächsten Test-Stufe sollen manuelle und EDI-unterstützte Transaktionen parallel durchgeführt werden. Dieser Test soll den Vergleich beider Systeme ermöglichen und bestehende Abweichungen aufdecken. Auf der letzten Test-Stufe soll für eine limitierte Anzahl an Transaktionen das EDI-System ohne das bisherige manuelle System geprüft werden. Dieser Test stellt den letzten Schritt vor der umfassenden EDI-Implementierung dar. Die elfte Phase beinhaltet die Auswertung der Testergebnisse sowie die Anpassung der Vorabversion. Diese Phase sollte solange durchgeführt werden, bis sich alle Nutzer mit dem EDI-System zufrieden gestellt sind. In der zwölften Phase ist die Vorabversion der vorangegangenen Phasen zu erweitern. Zur Planung der Erweiterung ist ein Implementierungszeitplan aufzustellen. Dabei wird empfohlen, das System um entweder weitere Transaktionen oder, um weitere Geschäftspartner zu erweitern. Vermieden werden soll hingegen die gleichzeitige Erweiterung um neue Transaktionen sowie neue Geschäftspartner. In der abschließenden dreizehnten Phase sollen die Implementierungsaktivitäten umfangreich publiziert werden. Dabei ist mit einer unternehmensinternen Veröffentlichung der Ergebnisse und erster Nutzeffekte zu beginnen. Zu einem fortgeschrittenen Zeitpunkt soll des Weiteren eine unternehmensexterne Veröffentlichung erfolgen. Aus der überwiegenden Zahl der zuvor beschriebenen Aktivitäten lassen sich Ergebnisdokumente ableiten. Jedoch sind nicht für alle der oben aufgeführten Phasen Hinweise auf entsprechende Ergebnisse enthalten. Ferner finden sich – mit Ausnahme der Kosten-/ Nutzenaufstellung der sechsten Phase – keine Hinweise auf formalisierte Ergebnisdokumente.

110

Untersuchung bestehender Integrationsmethoden

Techniken Ebenfalls gehen aus dem Ansatz einige Techniken hervor, die im Folgenden beschrieben werden. In der vierten Phase schlägt Emmelhainz die Durchführung von Schulungen für die von der EDI-Implementierung betroffenen Akteure vor. Dazu ist eine Schulungsmatrix im Beitrag enthalten. Eine Dimension dieser Matrix bilden die von der EDIImplementierung betroffenen Akteure, wie die Unternehmensführung, die Nutzer sowie das EDI-Team. Diesen gegenübergestellt sind in der zweiten Dimension mögliche Schulungsinhalte, gruppiert in EDI-Übersicht, Standards, Software, Konfiguration sowie Implementierungsfragen. Mittels der Matrix lässt sich ermitteln, welche Schulungsinhalte für welche Akteure nötig, wünschenswert oder irrelevant sind. Zusätzlich zur Matrix werden im Anschluss mögliche Schulungsinhalte vorgestellt. In der fünften Phase soll anschließend die Ermittlung des Ist- und Soll-Systems erfolgen. Dazu sind im Beitrag von Emmelhainz zwei grobe Fragenkataloge enthalten, die sich dem jeweiligen System widmen. Mithilfe der Fragen wird die Analyse des derzeitigen und zukünftigen Informationsflusses sowie der Datenstrukturen der betroffenen Anwendungssysteme ermöglicht. Ausführlich widmet sich Emmelhainz der Kosten-/ Nutzenermittlung. Dazu sind die die anfallenden Kosten und mögliche Einsparungen durch die EDI-Nutzung strukturiert zu erfassen. Die Ermittlung endet jeweils in einer zusammenfassenden Übersicht, in die sich konkrete Kosten und Einsparungen für ein EDI-Projekt eintragen lassen. Zur Ermittlung des Gesamtergebnisses einer EDI-Nutzung ist abschließend eine nach Nutzungsjahren strukturierte Gegenüberstellung der Kosten und Einsparungen enthalten. Schließlich ist für die siebte Phase, in der die an der Implementierung beteiligten Akteure ausgewählt werden, ein knapper Fragenkatalog vorgesehen. Mit dessen Hilfe soll die Auswahl der Transaktion, des beteiligten Unternehmensbereichs sowie des Geschäftspartners ermittelt werden. Ebenfalls sind Hinweise zur Auswahl des EDIAnbieters sowie zur Wahl des Netzwerksbetreibers enthalten. Diese Hinweise werden durch eine Gegenüberstellung der bei der Erstellung der Integrationsmethode von Emmelhainz verbreiteten EDI-Software sowie von Netzwerkanbietern unterstützt.

Rollenmodell Gemäß dem enthaltenen Rollenmodell wird die Implementierung des EDI-Systems von einem fünf Gruppen umfassenden Projektteam durchgeführt (vgl. Abb. 3.2.4/2). Jede der aufgeführten Gruppen setzt sich aus Mitarbeitern unterschiedlicher Bereiche zusammen. Ebenso kommen jeder Gruppe spezifische Aktivitäten zu.

Detaillierte Analyse ausgewählter Integrationsmethoden

111

EDI Leadership Group Senior EDI Manager EDI Project Manager EDI Coordinator

Staff Support Group Legal and Audit Training and Coordinator

Operations Group Functional Managers Functional Coordinators

Technical Group Communications Specialist Applications Specialist Technical Coordinator

Liaison Group Salesperson Trading Partner Coordinator

Abb. 3.2.4/2: Organigramm eines EDI-Projektteams nach Emmelhainz

Die EDI Leadership Group sollte sich im Wesentlichen aus Mitgliedern mit betriebswirtschaftlichem Hintergrund zusammensetzen (im Vergleich zu einem technischen Hintergrund). Dies wird die vorrangige Aufgabe der Leadership Group begründen. So ist die Gruppe für die Koordination verschiedener an der EDI-Implementierung beteiligter Funktionalbereiche zuständig. Ebenfalls ist diese Gruppe für die Projektführung und -aufsicht, die Bestimmung der EDI-Anwendungsbereiche und dessen Gestaltung, die Kommunikation mit der Unternehmensführung sowie für die Beschaffung nötiger Ressourcen zuständig. Die Operations Group setzt sich aus leitenden Mitarbeitern von der EDIImplementierung betroffener Fachbereiche zusammen (beispielsweise aus der Beschaffung oder der Logistik). Die Aufgaben der Gruppe umfassen die Identifizierung von EDI-Anwendungen im entsprechenden Unternehmensbereich, die Priorisierung von möglichen EDI-Anwendungen sowie die Gestaltung neuer Prozesse. Die Technical Group ist mit Mitarbeitern mit technischem Hintergrund und vor allem aus dem IT-Bereich eines Unternehmens besetzt. Die vorrangige Aufgabe dieser Gruppe erstreckt sich auf die Erklärung der bisher verwendeten Systeme sowie auf die Integration der EDI-Software in die Systemlandschaft des Unternehmens. Ferner ist die Liaison Group aus Mitarbeitern der Bereiche Vertrieb, Kundenservice und Marketing zu bilden. Die Aufgabe dieser Gruppe liegt in der unternehmensinternen sowie unternehmensexternen Bekanntmachung der EDI-Aktivitäten. Des Weiteren ist diese Gruppe für die Auswahl der Geschäftspartner für den Test der Vorabversion sowie für die Überwachung des Status der EDI-Implementierungsaktivitäten der Geschäftspartner zuständig. Die Staff Support Group setzt sich schließlich aus Mitarbeitern der Funktionsbereiche, der Rechtsabteilung sowie des Rechnungswesens zusammen. Die Gruppe ist für die Begutachtung der EDI-Implementierung aus rechtlicher Sicht beziehungswei-

112

Untersuchung bestehender Integrationsmethoden

se aus Sicht des Rechnungswesens zuständig. Zusätzlich werden die EDISchulungen von der Staff Support Group entwickelt und durchgeführt. 3.3

Zusammenfassende Bewertung der analysierten Integrationsmethoden

3.3.1 Gegenüberstellung Anhand der vorangestellten Analyse der Integrationsmethoden erfolgt im Folgenden ihre Gegenüberstellung. In Anlehnung an die bereits durchgeführte Gegenüberstellung des Vorgehens in der Praxis ist Gegenüberstellung der Methoden aus der Literatur ebenfalls anhand des detaillierten Rasters strukturiert.290

Gestaltungsfelder Aus der Betrachtung der Gestaltungsfelder lässt sich die angestrebte Integrationsarchitektur der jeweiligen Methode entnehmen. Die Methoden von ARIS sowie Emmelhainz sind auf einen Integrationsmechanismus beschränkt. ARIS verfolgt die Integration mittels integrierter Anwendungssysteme im Sinne eines Applikations-Sharings.291 Emmelhainz hingegen zielt auf die Integration durch den Austausch von Nachrichten im Sinne einer Applikations-Kommunikation ab. Im Vergleich zu diesen Methoden, mit dem Fokus auf eine einzige Integrationsarchitektur, unterstützen die Ansätze von FORWIN und St. Gallen mehrere Integrationsarchitekturen. Die FORWIN-Methode zielt im Rahmen der datenorientierten Kopplungsarchitektur auf die gemeinsame Nutzung von Daten im Sinne eines Daten-Sharings sowie auf die Datenübertragung zwischen Anwendungssystemen gemäß der Applikations-Kommunikation. Darüber hinaus wird bei der ereignisorientierten Kopplungsarchitektur nach FORWIN der Austausch von Nachrichten zwischen Anwendungssystemen im Sinne einer Applikations-Kommunikation ermöglicht. Schließlich wird die gemeinsame Nutzung von Funktionsmodulen bei der funktionsorientierten Kopplungsarchitektur nach einem Applikations-Sharing im Rahmen der Methode thematisiert. Der St. Galler Ansatz enthält durch die Unterscheidung der Integration über Schnittstellen (für eine ApplikationsKommunikation) eine gemeinsame Datennutzung (im Sinne eines Daten-Sharings) sowie über gemeinsame Applikationen (im Sinne eines Applikations-Sharings) ebenfalls mehrere Integrationsarchitekturen. Zu bemerken ist, dass sich die Wahl unterschiedlicher Architekturen nicht auf die Ausgestaltung der Methode auswirkt. Ent-

290 291

Vgl. Kapitel 2.2.3 Vgl. zur Integration mittels Anwendungssystemen am Beispiel von ERP-Systemen Biehl/Kim (2003), S. 274-276.

Zusammenfassende Bewertung der analysierten Integrationsmethoden

113

sprechend divergiert das Vorgehen innerhalb eines Ansatzes trotz der Unterstützung unterschiedlicher Integrationsarchitekturen nicht. Ein weiterer Unterschied zwischen den Ansätzen zeigt sich im Hinblick auf den nötigen Eingriff in die bestehenden Anwendungssysteme. Ein Teil der Ansätze realisiert die Integration ohne dass die bestehenden Anwendungssysteme dafür modifiziert werden müssen. Bei der Integrationsmethode von ARIS findet dies etwa durch die Entwicklung eines integrierten Systems statt, das die bestehenden Systeme ersetzt. Im Vergleich dazu lässt sich etwa beim FORWIN-Ansatz die Schnittstellenentwicklung und damit der Eingriff in die bestehenden Anwendungssysteme nicht umgehen.

Allgemeine Aktivitäten Alle vorgestellten Methoden zur Integration von Anwendungssystemen sind in unterschiedliche Phasen unterteilt. Im Kern unterscheiden sich diese hauptsächlich hinsichtlich ihrer Granularität. Insgesamt lassen sich sämtliche Aktivitäten in fünf Phasen einordnen. Sie umfassen die (1) Identifizierung von Integrationsbereichen, deren (2) Bewertung, die (3) Konzeption einer Integrationslösung, deren (4) Implementierung sowie die (5) Nutzung und Anpassung. Beim Vergleich der Abdeckung der Phasen durch die in den Methoden enthaltenen Aktivitäten lassen sich Ähnlichkeiten bei den Ansätzen von FORWIN und ARIS finden. Diese konzentrieren sich insbesondere auf die Identifizierung von Integrationsbereichen sowie die Konzeption des Integrationsmechanismus bzw. des integrierten Anwendungssystems. Im Vergleich dazu werden im Rahmen der Methoden von St. Gallen und Emmelhainz Aktivitäten zur Bewertung von Integrationsbereichen, (bei Emmelhainz nur ansatzweise) zur Implementierung und bei St. Gallen auch für die Identifizierung und Anpassung von Integrationsbereichen vorgestellt (vgl. Abb. 3.3.1/1). FORWIN ARIS St. Gallen

Emmelhainz Identifizierung

Bewertung

Konzeption

Implementierung

Nutzung und Anpassung

Abb. 3.3.1/1: Berücksichtigte Aktivitäten der Methoden292

292

Wichtig erscheint die Anmerkung, dass im Rahmen dieser Analyse lediglich Aktivitäten der jeweiligen Phasen untersucht wurden. Entsprechend sind mögliche Techniken innerhalb der Phasen nicht berücksichtigt.

114

Untersuchung bestehender Integrationsmethoden

Ergebnismodell Das Ergebnismodell ist typischerweise in den Ansätzen rudimentär beschrieben. Eine Ausnahme stellt dabei der St. Galler Ansatz dar, der umfassend auf bedeutende Dokumente eingeht und Beispieldokumente vorstellt. Typische Ergebnisdokumente für Integrationsmethoden sind Prozessmodelle für die Identifizierung von Integrationsbereichen, tabellarische Aufstellungen zur Ermittlung der Wirtschaftlichkeit sowie Daten- und Funktionsmodelle zur Konzeption der Integrationslösung. Zwei grundsätzliche Arten lassen sich in Form von formalisierten und nicht formalisierten Ergebnisdokumenten unterscheiden. Formalisierte Ergebnisdokumente werden insbesondere im Rahmen der Identifizierung und Konzeption des Integrationsbereichs erstellt, wie etwa in Form eines entsprechenden Prozess-, Daten- oder Funktionsmodells. Geringer formalisierte Ergebnisdokumente hingegen stellen die Methoden etwa bei der Bewertung von Integrationsbereichen vor.

Techniken Mit Ausnahme von ARIS enthält keine Methode durchgängig Techniken zur methodischen Unterstützung sämtlicher Phasen des Integrationsvorgehens.293 Im Folgenden werden die Techniken der Methoden im Detail gegenübergestellt: Außer im Ansatz von Emmelhainz enthalten sämtliche Integrationsmethoden Techniken zur Identifizierung von Integrationsbereichen. Im Kern wird dabei als Ausgangspunkt die Ermittlung des betroffenen Geschäftsprozesses vorgeschlagen, um daraus auf die Interdependenzen zwischen der Informationsverarbeitung zu schließen. Unterschiede zeigen sich zwischen den Ansätzen jedoch im Hinblick auf das vorgeschlagene Instrumentarium zur Identifikation. So lassen sich die vorgestellten Techniken zwei Richtungen zuordnen. Die Vorschläge von FORWIN (SOM) und ARIS (EPKs) sind grundsätzlich formal gehalten und damit mehrheitlich technisch orientiert. Hingegen ist das vorgeschlagene Instrumentarium des St. Galler Ansatzes in Form der Wertkettenanalyse, des Geschäftsfunktionssystems und der groben Datenflusspläne wenig formal und vergleichsweise managementorientiert (vgl. Abb. 3.3.1/2).

293

Zu beachten ist dabei jedoch der Fokus von ARIS auf die Phasen der Identifizierung und Konzeption der Integrationslösung. Für die Integrationsaktivitäten der Bewertung, Implementierung und Wartung sind somit auch hier keine Techniken zu finden.

Zusammenfassende Bewertung der analysierten Integrationsmethoden

115

Identifizierung von Integrationsbereichen

formal / technisch orientierte Ansätze z.B. semantisches Objektmodell

nicht-formal / managementorientierte Ansätze z.B. Wertkettenanalyse

Abb. 3.3.1/2: Methodische Unterstützung zur Identifizierung von Integrationsbereichen

Zwei unterschiedliche Zugänge zeigen sich ebenfalls bei der methodischen Unterstützung des ermittelten Funktionsumfangs. Ein Teil der Ansätze leitet den Funktionsumfang des Integrationsmechanismus direkt aus den identifizierten Integrationsbereichen ab. Entsprechend gehen diese Ansätze nicht auf einen erweiterten Funktionsumfang ein, der über die identifizierten Integrationsbereiche hinausgeht. Bei der FORWIN und St. Galler Integrationsmethode ist dies der Fall. Im Gegensatz dazu wird bei den Integrationsmethoden von ARIS und Emmelhainz der Funktionsumfang des Integrationsmechanismus gesondert methodisch unterstützt. Bei ARIS wird dafür die Erstellung eines Soll-Prozesses mittels eines Vorgangskettendiagramms unter Berücksichtigung der angestrebten Integrationslösung vorgestellt. Insofern geht der Ansatz über die Prozessoptimierung lediglich durch eine Verbesserung der zugrunde liegenden Anwendungssystemlandschaft hinaus. Eine andere methodische Unterstützung zur Ermittlung des Funktionsumfangs wird von Emmelhainz mit der Durchführung eines EDI Audits zur Detailanalyse des mittels EDI zu ersetzenden manuellen Informationsaustauschs im Ansatz vorgestellt. Zwei Ansätze enthalten methodische Hinweise zur Ermittlung nicht-funktionaler Anforderungen. Vergleichbar sind die Ansätze dabei insofern, als die Ermittlung jeweils anhand vorgegebener Kategorien erfolgt. Bei FORWIN sind dazu die Kategorien Flexibilität, Echtzeitverhalten, Integration und Korrektheit der Integrationslösung zu betrachten. ARIS hingegen ermittelt nicht-funktionale Anforderungen durch die Analyse der Systemnutzer, des benötigten Rechnernetzes sowie der Hardware zum Betrieb. Ähnlichkeiten zeigen sich im Hinblick auf die methodischen Hinweise zur Auswahl der Integrationsarchitektur. Diese erfolgt im Kern ausgehend von den funktionalen Anforderungen an die Integrationslösung. Ausgangspunkt ist dabei die Analyse der vom Integrationsbereich betroffenen Integrationsgegenstände. Die St. Galler Integrationsmethode erweitert die Architekturermittlung um die Frage möglicher Integrationsziele, bei der im Kern über dezentrale oder zentrale Architekturen entschieden wird. Unterschiede hinsichtlich der Architekturauswahl ergeben sich dagegen hinsichtlich der Verankerung der Auswahl in verschiedenen Phasen der Methode. So wird zum einen, ausgehend von den Eigenschaften des Integrationsbereichs und den

116

Untersuchung bestehender Integrationsmethoden

dort untersuchten Beziehungen zwischen den bestehenden Anwendungssystemen auf die zu wählende Integrationsarchitektur geschlossen. Zum anderen leiten sich die Integrationsarchitekturen vom Integrationsgegenstand unter Zuhilfenahme von generellen Integrationszielen ab. Bei der methodischen Unterstützung der Bewertung von Integrationslösungen steht die Erfassung von quantitativen Kosten und Nutzen zur Ermittlung der Amortisierungsdauer des Integrationsprojekts im Vordergrund. Dazu sind Hinweise auf typische Treiber der Integrationskosten sowie monetäre Nutzeffekte enthalten. Auf qualitative Effekte, wie etwa schnellere Informationsverfügbarkeit durch die Integration, wird in beiden Ansätzen hingegen nur ansatzweise eingegangen. In allen Ansätzen sind Techniken zur Konzeption von Integrationslösungen enthalten. Ihre Gegenüberstellung deckt im Kern zwei mögliche Zugänge der methodischen Unterstützung zur Konzeption auf: Unterschiede ergeben sich hinsichtlich der Ziele, die mit den aufgeführten Techniken angestrebt werden. So liegt der Fokus im Rahmen der Beiträge von ARIS und FORWIN auf einer detaillierten und formalisierten Modellierung der Integrationslösung im Sinne eines technisch orientierten Zugangs. Die Beiträge von St. Gallen und Emmelhainz gehen hingegen nur bedingt auf eine detaillierte Modellierung der Integrationslösung ein. Ihr Fokus liegt vielmehr in einer managementorientierten Vorbereitung des Integrationsprojekts.

Rollen Auf Rollen innerhalb von Integrationsprojekten wurde lediglich im Rahmen der Ansätze von St. Gallen und Emmelhainz eingegangen. Beide Zugänge schlagen grundsätzlich eine hierarchische Struktur der Organisation mit einer weisungsbefugten Projektleitung sowie dieser unterstellten Projektmitarbeitern vor. Trotz der Gemeinsamkeit enthalten die Methoden unterschiedliche Zugänge zur Organisation. Im Rahmen des St. Galler Ansatzes wird vor allem die Etablierung unterschiedlicher zentraler und dezentraler Rollen fokussiert. Zentrale Rollen sind dabei von Akteuren einzunehmen, die für die Identifizierung und Bewertung der Integrationsbereiche gemäß der Unternehmensstrategie verantwortlich sind. Dezentrale Rollen finden sich hingegen für die Steuerung eines verabschiedeten Integrationsbereichs. Bei Emmelhainz wird indes nicht auf zentrale und dezentrale Rollen eingegangen. Vielmehr zielt das Rollenmodell auf den Aufbau eines Projektteams mit verschiedenen Verantwortungsbereichen ab. Hinweise werden zusätzlich zum vorausgesetzten Hintergrund der handelnden Akteure gegeben, die einem Bereich des Projektteams zugeordnet werden sollen. Dabei sind prinzipiell technische oder betriebswirtschaftliche sowie fachliche Hintergründe ausschlaggebend.

Zusammenfassende Bewertung der analysierten Integrationsmethoden

117

Abb. 3.3.1/3 fasst die Gegenüberstellung der Integrationsmethoden übersichtsartig zusammen.

Metamodell

FORWIN

Gestaltungsfelder

Vorgehens- und Ergebnismodell

allgemeines Vorgehen

Dokumentation der Identifizierung von Integrationsbereichen

Dokumentation der Bewertung der Integrationslösung

Dokumentation der Konzeption der Integrationslösung

Identifizierung des Integrationsbereichs

Techniken

Ermittlung des Funktionsumfangs

Ermittlung nichtfunktionaler Anforderungen

Auswahl der Integrationsarchitektur

Bewertung von Integrationslösungen

Rollenmodell

Konzeption der Integrationslösung

Rollen bei Integrationsprojekten

Integrationsmechanismus bestehend aus Schnittstellenund Nachrichtenkomponete

ARIS

St. Galler ISM

Soll-Prozess Integrationsmechanismus oder integriertes integriertes Anwendungssystem bestehend Anwendungssystem bestehend aus Funktions-, Daten- und aus Funktions-, Daten- und Steuerungskomponente Steuerungskomponete

9 Phasen;

4 Phasen;

4 Phasen;

Im Kern: Identifizierung Æ Konzeption Æ Umestzung

Identifizierung Æ Fachkonzept Æ DV-Konzept Æ Umsetzung

Identifizierung Æ Bewertung Æ Konzeption Æ Umsetzung und Anpassung

semantisches Objektmodell

Vorgangskettendiagramm

Æ formalisiert; detailliert

Æ formalisiert; detalliert

-

-

Wertketten und Geschäftsfunktionssystem, Datenflussplan

Emmelhainz

Integrationsmechanismus bestehend aus Nachrichtenkomponente und Schnittstelle 13 Phasen; Im Kern: Vorbereitung Æ Bewertung Æ Konzeption Æ Pilotierung

-

Æ teilweise formalisiert; detailliert Bericht zur Abgrenzung des Integrationsbereichs

Quantifizierbare Kosten- / Nutzenaufstellung

nicht formalisiert; grob

nicht formalisiert; detailliert Transaktionsspezifikation

Modellierungsergebnisse (Funktionskomponenten, Prozess,…)

Dokumenation der Fach- und DV-Sicht

Teilsichten der Informationssystemarchitektur

Æ formalisiert; detailliert

Æ formalisiert; detalliert

Æ formalisiert; detailliert

Geschäftsprozessmodell aus Interaktionsschema und Vorgangs-Ereignis-Schema

Ermittlung des Ist-Vorgangs mit Geschäftsprozessmodell / Vorgangskettendiagramm

Wertkettenanalyse und Identifizierung der Informationsverarbeitung

-

aus identifizierten Integrationsbereichen

Ermittlung des Soll-Vorgangs mit Geschäftsprozessmodell / Vorgangskettendiagramm

aus identifizierten Integrationsbereichen

EDI-Audit

Kategorisierungskatalog

Ermittlung von Nutzern, Rechnernetz und benötigter Hardware im Rahmen der Organisationssicht

-

-

Ermittlung von Aufgabenintegrationsmustern (AIM) zur Abgrenzung von Integrationsgegenständen

-

Integrationsgegenstände und -ziele zur Ermittlung von Integrationsarchitekturen

-

-

-

qualitative / quantitative Kosten- / Nutzenanalyse; Ermittlung der Amortisationsdauer;

quantitative Kosten- / Nutzenanalyse; Ermittlung der Amortisationsdauer

Modellierung der Daten-, Funktions- und Organisationssicht

Fragenkatalog zur Ermittlung des Soll-Systems sowie zur Auswahl der Projektbeteiligten

Modellierung der Daten-, Modellierung der SchnittstellenFunktions-, Steuerungs- und und Nachrichtenkomponente Leistungssicht

Æ nicht formalisiert; grob

zentral: IS-Auschuss, IS-Leiter, Entwicklung -

-

Projektteam bestehend aus fünf Gruppen, zusammengesetzt aus dezentral: Projektleiter, Personen mit unterschiedlichen Projektausschuss, IS-Leiter, ISHintergründen Ausschuss

Abb. 3.3.1/3: Gegenüberstellung der Integrationsmethoden

3.3.2 Beurteilung der Integrationsmethoden In Kapitel 2.3 wurden Anforderungen an eine Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken vorgestellt. Darauf aufbauen wird im Folgenden skizziert, inwiefern die Methoden der Literatur die abgeleiteten Anforderun-

118

Untersuchung bestehender Integrationsmethoden

gen erfüllen. Ersichtlich wird daraus, dass keine der bestehenden Integrationsmethoden der Literatur sämtliche netzwerkspezifischen Anforderungen erfüllt.

Gestaltungsfelder Kaum eine Methode unterstützt verschiedene Integrationsarchitekturen. Lediglich die St. Galler Integrationsmethode thematisiert konkret unterschiedliche Ausgestaltungsformen. Innerhalb des Ansatzes von FORWIN wird lediglich die Unterstützung unterschiedlicher Integrationsgegenstände, wie Daten oder Funktionen behandelt. Der grundsätzliche Aufbau des Integrationsmechanismus ist davon jedoch nicht betroffen. Die weiteren Ansätze gehen auf eine konkrete Unterscheidung hingegen nicht ein. Entsprechend dieser fehlenden Unterscheidung besteht auch nur im Rahmen der St. Galler Integrationsmethode die Möglichkeit, die Integration über eine Anpassung der bestehenden Systeme sowie auch ohne Anpassung zu realisieren. Im Falle von FORWIN und Emmelhainz wird die Integration hingegen nur mit Anpassung und bei ARIS hingegen ausschließlich ohne eine solche möglich. Die Anpassung des zugrunde liegenden Ablaufs wird schließlich lediglich im Rahmen der ARIS Methode thematisiert. Die weiteren Methoden setzten den Ablauf als gegeben voraus.

Aktivitäten- und Ergebnismodell Die ermittelten Anforderungen zum Aktivitätenmodell werden von den untersuchten Integrationsmethoden kaum erfüllt. Lediglich der Ansatz von St. Gallen beinhaltet mit der Identifizierung, Konzeption und Bewertung alle vorgestellten Kernaktivitäten. Im Rahmen von FORWIN sowie ARIS wird die Bewertung und bei der Methode von Emmelhainz die Identifizierung nicht thematisiert. Ein inkrementelles Vorgehen mit Abbruchstellen lässt sich bei keinem der Ansätze finden. Wiederholungen der Aktivitäten sind nicht vorgesehen. Lediglich bei FORWIN wird darauf eingegangen, dass eventuell Rückschritte nötig sind, sofern es zu keinen Ergebnissen kommt. Als Abbruchstellen können hingegen die Wirtschaftlichkeitsbeurteilungen im Rahmen der St. Galler Methoden und des Ansatzes von Emmelhainz aufgeführt werden. Ein steigender Detaillierungs- und Formalisierungsgrad lässt sich meist nicht eindeutig aus den Ansätzen entnehmen. Durch die Erstellung zunächst eines Fach- und in dessen Anschluss eines DV-Konzepts ist lediglich bei der ARIS-Integrationsmethode diese Anforderung erfüllt. Die anderen Methoden kennzeichnen sich hingegen durch ein heterogenes Bild der Ergebnisdokumente, die je nach Technik formalisiert und detailliert sind, wobei dies nicht in Bezug zum Fortschritt des Integrationsprojekts steht.

Zusammenfassende Bewertung der analysierten Integrationsmethoden

119

Techniken Wie bereits aus der Gegenüberstellung der Methoden ersichtlich wurde, findet sich kein Ansatz, der für sämtliche Aktivitäten durchgängig eine methodische Unterstützung bereitstellt. Ein steigender Detaillierungsgrad ist lediglich in der Methode von ARIS enthalten. Die Berücksichtigung von überblicksartigen Techniken, die zu Projektbeginn ohne bedeutenden Aufwand bzw. Investitionen durchzuführen sind, um den Projektbereich zunächst grob abzustecken, lassen sich aus den weiteren Methoden nicht in vergleichbarer Weise entnehmen.

Rollenmodell Keine der ermittelten Anforderungen an das Rollenmodell für eine Methode der Integrationsplanung und -bewertung wird innerhalb der untersuchten Integrationsmethoden der Literatur erfüllt. Lediglich auffinden lassen sich hierarchische Projektorganisationen bei den Ansätzen von St. Gallen und Emmelhainz. Heterarchische Projektorganisationen sind ebenso wenig enthalten wie die Berücksichtigung von unterschiedlichen Varianten der Rollenbesetzung, etwa zum Ausgleich fehlender Kompetenzen durch externe Projektbeteiligte. In Abb. 3.3.2/1 sind die Anforderungen an die Methode den analysierten Methoden gegenübergestellt. Der mangelnden Erfüllung der ermittelten Anforderungen entsprechend stellt Kapitel 4 einen möglichen Methodenansatz vor.

mit und ohne Systemanpassung

Anpassung des Ablaufs

Beinhaltet alle Kernaktivitäten inkrementelles Vorgehen mit Abbruchstellen

Techniken

steigender Formalisierungsgrad der Ergebnisdokumente durchgängige methodische Unterstützung

Rollenmodell

Aktivitäten- und Ergebnismodell

Gestaltungsfelder

Anforderung unterschiedliche Integrationsmechanismen

hierarchische und heterarchische Organisation

steigender Detaillierungsgrad der Techniken

Varianten der Rollenbesetzung

FORWIN

ARIS

St. Gallen

Emmelhainz

2 2 2 2 2 2 2 2 2 2

2 2 3 2 2 3 2 3 2 2

3 3 2 3 2 2 2 2 2 2

2 2 2 2 2 2 2 2 2 2

Abb. 3.3.2/1: Beurteilung der untersuchten Integrationsmethoden

4 Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken Die vorangestellte Methodenanalyse deckte Gemeinsamkeiten und Unterschiede zwischen den vorgeschlagenen Ansätzen in der Literatur auf. Zusätzlich verdeutlicht sie Defizite der Methoden im Hinblick auf die ermittelten Anforderungen einer Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken. Aufbauend auf den beschriebenen Grundlagen der Unternehmensnetzwerke und der zwischenbetrieblichen Integration, den ermittelten Anforderungen an eine Methode sowie den analysierten Methoden der Literatur wird im folgenden Abschnitt ein Method entworfen. Der Ansatz orientiert sich in seiner Aufbereitung an den Komponenten des Method Engineerings. Nachdem die Eckpunkte der Methode in Kapitel 4.1 skizziert werden, enthält Kapitel 4.2 das Metamodell und Kapitel 4.3 das Vorgehensmodell der Methode. Kapitel 4.4 stellt im Anschluss die Techniken, Kapitel 4.5 die daraus resultierende Ergebnisdokumente sowie Kapitel 4.6 schließlich das Rollenmodell der Methode vor. 4.1

Eckpfeiler der Methode

Um die ermittelten Anforderungen zu erfüllen, geht die Methode von den im Folgenden dargestellten vier Eckpunkten aus.

Berücksichtigung netzwerkspezifischer Besonderheiten Innerhalb des Grundlagenkapitels wurden Unternehmensnetzwerke durch fünf Kriterien von anderen Organisationsformen abgegrenzt.294 Eine Methode zur Anwendungssystemintegration in Netzwerken muss diese Charakteristika sowie die sich daraus ergebenden netzwerkspezifischen Besonderheiten berücksichtigen.295 Entsprechend sind Methodenkomponenten zu wählen bzw. zu entwickeln, die den besonderen Herausforderungen eines Netzwerks im Vergleich zu anderen und insbesondere den klassischen Organisationsformen gerecht werden.296 Im Verlauf der Methodenbeschreibung werden demzufolge die Besonderheiten und die sich daraus 294

295

296

Die Kriterien umfassten die (1) rechtliche und wirtschaftliche Selbständigkeit der Partnerunternehmen mit dem Ziel der (2) gemeinsamen Erstellung einer Marktleistung. Dazu stimmen die Netzwerkpartner (3) formlos oder auf vertraglicher Basis ihre Funktionen ab. An der (4) unbefristeten Zusammenarbeit im Netzwerk sind schließlich (5) mindestens drei, meist jedoch oft zehn und mehr Partner beteiligt (vgl. Kapitel 2.1.1.2 und 2.1.1.3). Etwa dadurch, dass geeignete Mechanismen enthalten sind, um die fehlende Weisungsbefugnisse aufgrund der Selbständigkeit der Partnerunternehmen auszugleichen oder indem das weitgehende Fehlen von Ressourcen aufgrund der Funktionsabstimmung innerhalb eines Netzwerks kompensiert wird. Vgl. zu den Herausforderungen für Instrumente einer Netzwerkorganisation etwa Balke/Küpper (2003), S. 943-945; Hess/Wittenberg (2005), S. 53; Ringel et al. (2005), S. 148.

122

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

ergebende Erweiterung des Integrationsvorgehens für einen netzwerkspezifischen Einsatz explizit herausgestellt.

Fokussierung der Integrationsplanung und -bewertung Innerhalb des Grundlagenkapitels zu Unternehmensnetzwerken wurde ebenfalls auf verschiedene Bereiche des Netzwerksmanagements eingegangen. Unterschieden wurde dabei zwischen dem Plattform- und dem Produktionsmanagement.297 Ersteres fokussiert langfristige und grundsätzliche Aspekte des Netzwerks, die auf der Beziehungsebene angesiedelt sind. Im Vergleich dazu betrachtet Letzteres hingegen operative Aspekte auf der Leistungsebene des Netzwerks. Eine vollständige Durchführung von Integrationsprojekten von der Planung bis zur Einführung betrifft sowohl das Plattform- als auch das Produktionsmanagement. Zum Plattformmanagement zählen im Rahmen von Integrationsprojekten Aktivitäten der Identifizierung von Integrationsbereichen sowie die Konzeption und Bewertung von Integrationslösungen, die im Folgenden als Integrationsplanung und -bewertung bezeichnet werden. Hingegen gehört die Implementierung der Integrationslösung mehrheitlich zum Produktionsmanagement, zu dem die Umsetzung netzwerkbezogener Projekte zählt.298 Zu dessen Unterstützung hat die Forschung des Themenkomplexes Netzwerkmanagement eine Vielzahl von Instrumenten entwickelt. Diese lassen sich auch auf die Implementierung einer Integrationslösung von Netzwerken übertragen, sofern die Managementprozesse des Netzwerks betroffen sind.299 Sind ferner technische Details von Bedeutung, so lässt sich auf bestehende Integrationsmethoden sowie Verfahren der Softwareentwicklung zurückgreifen. Begründen lässt sich dies, da Unternehmensnetzwerke – sofern eine detaillierte Spezifikation der Integrationslösung vorgenommen wurde – im Hinblick auf die technische Realisierung der Integration etwa im Vergleich zu einem Konzern mit weltweit verteilten Töchterunternehmen keine explizit zu berücksichtigenden Besonderheiten aufweisen. Hintergrund davon sind die verminderten Handlungsspielräume, die sich bei der Entwicklung von Anwendungssystemen ergeben, sofern eine detaillierte Konzeption – etwa in Form einer detaillierten Spezifikation – vorgenommen wurde.300 Vermehrt existieren hingegen Handlungsspielräu297 298

299

300

Vgl. Kapitel 2.1.1.3. Da es sich bei der Implementierung einer Integrationslösung um einen internen Netzwerkauftrag handelt, zählt dies im Rahmen des Produktionsmanagements gemäß Wohlgemuth zum Projektmanagement (vgl. Wohlgemuth (2002) S. 40). Von Bedeutung sind dabei insbesondere Spezifikation und Vergabe von Teilaufgaben unter den Netzwerkpartnern, die Festlegung des Auftragspreises sowie die Kontrolle der Auftragsabwicklung, wozu umfassende Vorschläge für Instrumente existieren (vgl. etwa Hess (2002a), S. 151214). Mit der Spezifikation wird festgehalten, „was“ das System leisten soll. Handlungsspielräume ergeben sich entsprechend lediglich im Hinblick auf Entwurfs- und Implementierungsentscheidungen (vgl. Balzert (2000), S. 113). Auch im Netzwerk ist jedoch nicht zu erwarten, dass diese jeweils

Eckpfeiler der Methode

123

me für das Netzwerk in den Phasen bis zur fachkonzeptionellen Spezifikation.301 Entsprechend bezieht sich der Methodenansatz insbesondere auf die Integrationsplanung und -bewertung in Netzwerken. Damit sind die die Projektphasen eines Integrationsprojekts fokussiert, in denen besonders viele Handlungsspielräume auftreten und die im Rahmen der Forschung zum Netzwerksmanagement bisher nur rudimentär berücksichtigt sind.

Konsequente Managementorientierung Bereits bei der Gegenüberstellung der Integrationsmethoden wurde auf die möglichen Zugänge zur Integration skizziert. Abgrenzen ließ sich dabei ein vermehrt technisch geprägter Blick auf Integrationsprojekte von einem mehrheitlich managementorientierten Blick auf die Integration. Oben wurde bereits auf die vernachlässigbaren Unterschiede technischer Aspekte der Integration bei Unternehmensnetzwerken im Vergleich zu anderen Organisationsformen eingegangen. Des Weiteren ist durch die ausgeprägte Konzentration der Netzwerkpartner lediglich auf ihre Kernkompetenzen regelmäßig das Fehlen eines netzwerkeigenen IT-Bereichs bzw. einzelner ITBereiche der Partnerunternehmen zu erwarten. Die tatsächliche Realisierung wird in diesen Fällen von netzwerkexternen Akteuren übernommen. Um den Einsatz der Methode in Netzwerken mit fehlenden fundierten technischen Kompetenzen gleichermaßen zu gewährleisten, wird konsequent ein managementorientierter Blick auf die Integration eingenommen. Diese Blickrichtung auf Integrationsprojekte wird nicht zuletzt gestützt durch das häufige Scheitern von EAI-Projekten aufgrund eines mangelhaften Managements der Integrationsprojekte302 sowie der Forderung nach einem geringen Installations- und Durchführungsaufwand von Instrumenten für das Netzwerkmanagement.303 Technische Kompetenzen für die Integrationsprojekte der Netzwerke sind gemäß der vorliegenden Methode erst im Rahmen der tatsächlichen Realisierung nötig. Aufgrund fehlender netzwerkspezifischer Besonderheiten und wissenschaftlich umfangreich erschlossener Ansätze ist die Realisierung von Anwendungssystemen – wie oben bereits dargestellt – hingegen nicht Gegenstand der vorliegenden Methode, so dass die konsequente Managementorientierung keine Beschränkung, sondern eine Erweiterung des Einsatzfeldes der Methode darstellt.

301

302

303

von den einzelnen Partnern übernommen werden. Vielmehr ist zu erwarten, dass ein einzelner Netzwerkpartner oder ein externes drittes Unternehmen die Implementierung übernimmt. Etwa bei Fragen zur gewünschten Funktionalität, Skalierbarkeit, Performance, Sicherheit des Systems (vgl. etwa Eckert et al. (2003), S. 100-102). Vgl. Yusuf et al. (2004), S. 251. Ähnlich argumentiert Linthicum, der die häufig anzutreffende Komplexität von Integrationsmethoden kritisiert (vgl. Linthicum (2000), S. 92). Vgl. Wohlgemuth (2002), S. 129.

124

4.2

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Metamodell

Zur Vereinfachung ist das im Folgenden vorgestellte Metamodell in zwei unterschiedliche Sichten unterteilt. Die erste Sicht (Integrationsbereiche) dient der Erfassung der Metamodellkomponenten, weitgehend unabhängig von der tatsächlich vom Netzwerk angestrebten Integrationslösung. Hingegen bezieht sich die zweite Sicht im Wesentlichen auf die vom Netzwerk angestrebte Integrationslösung, weitgehend unabhängig von ihrer Verortung im Netzwerk. Beide Sichten werden im Folgenden im Detail beschrieben. 4.2.1 Sicht „Integrationsbereich“ Die erste Sicht beinhaltet sämtliche Metamodellkomponenten, die von der Identifizierung und Evaluation eines Integrationsbereichs betroffen sind. Entsprechend bildet der Integrationsbereich die zentrale Komponente dieser Sicht. Integrationsbereiche ergeben sich zum einen aufgrund von Informationsobjekten, die von Anwendungssystemen unterschiedlicher Partnerunternehmen im Rahmen einer Kommunikationsbeziehung zwischen zwei Prozesskomponenten genutzt werden. Darüber hinaus ergeben sich Integrationsbereiche zum anderen durch Prozesse, denen bisher eine Anwendungssystemunterstützung des Netzwerks vollständig bzw. weitestgehend fehlt. Somit werden Integrationsbereiche zum einen durch Kommunikationsbeziehungen als Teil eines Prozesses und damit zwischen zwei Prozesskomponenten sowie zum anderen durch den Prozess selbst begrenzt.304 Die Aufdeckung der relevanten Prozesse für das Netzwerk ergibt sich aus dessen Zielsetzung, die durch die beteiligten Partnerunternehmen bestimmt wird. Erfolgsfaktoren unterstützen die Ziele. Sie dienen ebenfalls der Ermittlung der Bedeutung eines Integrationsbereichs, so dass lediglich Integrationsbereiche vom Netzwerk zu verfolgen sind, die dessen Erfolgsfaktoren unterstützen. Darüber hinaus ist die Bedeutung eines Integrationsbereichs von dessen Integrationsattraktivität begrenzt, in der Nutzen- und Risikoeffekte der Integration zusammengefasst sind.305 Abb. 4.2.1/1 zeigt die Zusammenhänge der Metamodellkomponenten in der Übersicht.

304 305

Vgl. im Detail die Identifizierung von Integrationsbereichen des Kapitels 4.4.2.2. Zur Attraktivität und Bedeutung von Integrationsbereichen vgl. Kapitel 4.4.3.2.

Metamodell

125

bestimmt

Anwendungssystem

Erfolgsfaktor

bestimmt

hat

begrenzt

besteht aus

Prozess gehört zu

benötigt / erstellt benötigt / erstellt

Informationsobjekt

Integrationsbedeuting

Integrationsbereich

hat

Integrationsattraktivität

begrenzt

Prozesskomponente

unterstützt

verfolgt

Ziel

besteht aus

gehört zu

nutzt

Partner

durchläuft

Kommunikationsbeziehung

ist Teil von

Abb. 4.2.1/1: Metamodell der Sicht „Integrationsbereiche“

4.2.2 Sicht „Integrationslösung“ Die Sicht Integrationslösung umfasst sämtliche Metamodellkomponenten, die von der Erfassung der Anforderungen an die Lösung sowie von der detaillierten Kosten- und Nutzenanalyse betroffen sind. Entsprechend bildet die Integrationslösung die zentrale Komponente dieser Sicht. Spezifiziert wird diese durch die Anforderungen, die von den Projektbeteiligten (Viewpoints) in Form einer Anforderungsspezifikation zusammengefasst sind. Viewpoints sind (in irgendeiner Art und Weise) betroffen vom Integrationsbereich, etwa da sie die für den Integrationsbereich eingesetzte Integrationslösung zukünftig zu warten haben. Ausgewählt werden sie durch die Netzwerkpartner. Innerhalb der Anforderungsspezifikation wird ebenfalls die für die Integration zu wählende Integrationsarchitektur definiert und bestimmt, ob der Integrationsbereich in Form eines Applikations-Sharings, Daten-Sharings oder via ApplikationsKommunikation realisiert wird. Grundsätzlich werden durch die Integrationslösung beteiligte Anwendungssysteme verbunden bzw. stellt die Integrationslösung selbst ein Anwendungssystem dar. Durch die Implementierung der Integrationslösung ergeben sich Kosten- und Nutzeffekte, die sich aus der Anforderungsspezifikation ableiten lassen und von den Partnern des Netzwerks zu übernehmen sind (vgl. Abb. 4.2.1/2).

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

ermittelt

Viewpoint

wählt aus

Partner

Anwendungssystem

besteht aus

verbindet / ist

Anforderung

spezifiziert

Integrationslösung

hat

Kosten / Nutzen

ist

Anforderungsspezifikation

Integrationsbereich

übernehmen / erhalten

ist betroffen vom

schließt

126

Integrationsarchitektur bestimmt

Abb. 4.2.1/2: Metamodell der Sicht „Integrationslösung“

4.3

Vorgehensmodell

Ein Vorgehensmodell beschreibt im Allgemeinen überblicksartig die Projektaktivitäten in ihrer chronologischen Reihenfolge. Das nachfolgend präsentierte Vorgehensmodell orientiert sich an den identifizierten Anforderungen der Aktivitäten des Integrationsprojekts aus Kapitel 2.3 sowie an dem Vorgehen der untersuchten Methoden des Kapitels 1. Den ermittelten Anforderungen zufolge werden insbesondere die Kernaktivitäten wie die Identifizierung von Integrationsbereichen sowie die Konzeption und Bewertung der Integrationslösung im Rahmen der Methode berücksichtigt. Die Methode entspricht ebenfalls der ermittelten Anforderung nach einem inkrementellen Vorgehen und der Beachtung von Abbruchstellen. Das inkrementelle Vorgehen vermindert hohe Investitionen ohne dass bekannt ist, ob das Projekt überhaupt durchgeführt wird.306 Dazu werden bestimmte Aktivitäten, wie etwa die Bewertung, zunächst rudimentär und im weiteren Verlauf vertiefend durchgeführt. Durch die Berücksichtigung möglicher Abbruchstellen ist darüber hinaus gewährleistet, dass das Projekt lediglich weitergeführt wird, sofern es aus Sicht der Projektbeteiligten als vorteilhaft erscheint. Die Analyse der Vorteilhaftigkeit wird im Rahmen der Methode durch entsprechende Techniken unterstützt. Unter Berücksichtigung der dargelegten Aspekte umfasst der Methodenvorschlag drei aufeinander aufbauende Phasen, die im Folgenden beschrieben werden (vgl. Abb. 4.3/1).

306

Vgl. Jung (1995), S. 545-547.

Vorgehensmodell

127

1 Identifizierung der Integrationsbereiche 2 Analyse der Integrationslösung

1. mögliche Abbruchstelle

3 Bewertung und Auswahl der Integrationslösung

2. mögliche Abbruchstelle

Abb. 4.3/1: Vorgehensmodell

Identifizierung der Integrationsbereiche Ausgangspunkt des Methodenansatzes ist die Identifizierung von Integrationsbereichen innerhalb des Netzwerks. Das Vorgehen dazu setzt sich aus zwei Teilschritten zusammen. Für die Ermittlung der Integrationsbereiche sind zunächst Netzwerkaufbau sowie die Netzwerkprozesse zu ermitteln. Ausgangspunkt des Vorgehens ist die Abgrenzung der Ziele des Netzwerks, anhand derer die Prozesse und daraus schließlich die Netzwerkprozessorganisation abgeleitet werden. 307 Die ermittelte Prozessorganisation bildet anschließend die Grundlage zur Ermittlung der Integrationsbereiche.308 Dies erfolgt durch die Analyse der bestehenden Informationsflüsse innerhalb der Prozesse und zwischen den Netzwerkpartnern sowie durch die Zuordnung der im Netzwerk eingesetzten Anwendungssysteme.309 Analyse der Integrationslösung Die identifizierten Integrationsbereiche werden in der zweiten Phase zunächst einer ersten Evaluation unterzogen. Dabei wird anhand des Integrationsbedarfs, der Unterstützung der Netzwerkziele sowie der Projektrisiken und des erwarteten Nutzens eine Auswahl der weiter zu verfolgenden Integrationsbereiche vorgenommen. Entsprechend finden solche Integrationsbereiche keine weitere Beachtung, die im Rahmen der Evaluation durch die Netzwerke wenig Potenzial bergen. Die Filterung der aus Sicht des Netzwerks als wenig relevant befundenen Integrationsbereiche stellt die erste Abbruchstelle der Integrationsmethode dar.

307

308

309

Vgl. Grant (2003), 165-167; Payton (2000), S. 317; Holland/Lockett (1992), S. 542. Dieser Schritt entfällt, sofern die Geschäftsstrategie des Netzwerks bereits in anderen Managementprozessen definiert wurde. Vgl. Katzy (2005), S. 43-44; Ho/Lin (2004), S. 3740-3742. Hintergrund dieses Vorgehens bildet das Strategic Alignment-Modell. Dieses stellt im Kern Zusammenhänge zwischen der Unternehmens- und der IT-Strategie sowie der Geschäfts- und der IT-Infrastruktur her und thematisiert damit den Bedarf ihrer gegenseitigen Abstimmung (vgl. Henderson/Venkatraman (1999)). Vgl. etwa Erdmann (2004), S. 75-76; Ciborra/Jelassi (1994), S. 43-44.

128

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Für die als relevant klassifizierten Integrationsbereiche werden anschließend die Anforderungen ermittelt. Entscheidend ist hierbei die Berücksichtigung sämtlicher Interessengruppen an der Integrationslösung zur Erfassung der funktionalen und nichtfunktionalen Anforderungen.310 In Form einer vom Netzwerk zu verabschiedenden Spezifikation der Integrationslösung sind die ermittelten Anforderungen detailliert zusammengefasst. Bewertung und Auswahl der Integrationslösung In der dritten Phase findet eine vertiefende Bewertung der möglichen Integrationslösungen sowie deren finale Auswahl statt. Die Bewertung erfolgt mit einer detaillierten Wirtschaftlichkeitsanalyse der infrage kommenden Integrationslösungen. Die Wirtschaftlichkeitsanalyse fließt schließlich in den Auswahlprozess einer Integrationslösung mit ein, der den Abschluss der dritten Phase bildet. Wie bereits in der zweiten Phase findet sich auch hier eine weitere Abbruchstelle des Integrationsprojekts. Ein Abbruch erfolgt an dieser Stelle, sofern sich keine der infrage kommenden Integrationslösungen aus Sicht der vertiefenden Wirtschaftlichkeitsanalyse als vorteilhaft erweist. 4.4

Techniken

Zentrale Bestandteile einer Methode bilden die im Folgenden beschriebenen methodischen Anweisungen zum Erhalt der Ergebnisdokumente. Sie stellen die Grundlage eines zielgerichteten Vorgehens bei der Integrationsplanung und -bewertung dar. Die vorgestellten Techniken stammen unter anderem aus dem Netzwerkmanagement bestehender Integrationsmethoden, dem allgemeinen Integrationsmanagement, dem Informationsmanagement sowie dem Software Engineering. Eignen sie sich – etwa aufgrund fehlender Berücksichtigung netzwerkspezifischer Eigenschaften – im Vorhinein nicht vollständig für die zugrunde liegende Fragestellung der Anwendungssystemintegration in Unternehmensnetzwerken, so werden sie entsprechend den Anforderungen an eine Netzwerkmethode angepasst. Zur Vorstellung der Techniken wurde ein einheitliches Schema gewählt. Dabei erfolgt in einem ersten Schritt zunächst die Einordnung der gewählten Technik anhand des Ziels ihres Einsatzes sowie den zu erwartenden Ergebnissen. Daraufhin wird das zugrunde liegende Vorgehen zur Durchführung der Technik im Detail dargestellt. Abb. 4.4/1 ordnet die verwendeten Techniken den Phasen zu und zeigt die zentralen Ergebnisse zur Übersicht.

310

Vgl. Sommerville (2001), S. 109-114.

Techniken

129

Techniken 1 Identifizierung der Integrationsbereiche

1. 2.

Ermittlung der Netzwerkprozessorganisation Identifikation der Integrationsbereiche

2 Analyse der Integrationslösung

3. 4.

zentrale Ergebnisse • Ziele, Prozesse und organisatorische Ausgestaltung • Integrationsbereiche aufgrund fehlender AS-Unterstützung • Integrationsbereiche zwischen AS

Evaluation der Integrationsbereiche Integrationsspezifikation

• Relevanzbeurteilung der Integrationsbereiche • Ableitung der Integrationsarchitekturen • Ermittlung und Dokumentation der Anforderungen

Integrations-Assessment

• Wirtschaftlichkeitsanalyse der Integrationslösung • Auswahl der zu realisierenden Integrationslösungen

3

Bewertung und Auswahl der Lösung

5.

Abb. 4.4/1: Techniken und ihre zentralen Ergebnisse

4.4.1 Ermittlung der Netzwerkprozessorganisation Die Ermittlung der Netzwerkorganisation, bestehend aus dem Netzwerkaufbau und den Netzwerkprozessen, bildet die Grundlage der Identifizierung der Integrationsbereiche in Netzwerken. Ausgangspunkt der Ermittlung ist die Analyse des Kooperationsgegenstandes und der sich daraus ergebenden Netzwerkziele, die als Grundlage zur Identifizierung der organisatorischen Ausgestaltung dienen.311 Darüber hinaus ist die Orientierung an übergeordneten Zielen im Sinne der „Goals“ oder “Mission Objectives“ unlängst als kritischer Erfolgsfaktor bei der Durchführung von Informationssystemprojekten – und damit folglich auch für die Anwendungssystemintegration als Spezialfall – bestätigt worden.312 Entsprechend dient die Ermittlung der Ziele des Netzwerks im weiteren Projektverlauf als Orientierungshilfe. 4.4.1.1

Ansatz

Im Rahmen der bereits bestehenden Methoden zur Integration von Anwendungssystemen ist die Ermittlung von Integrationsbereichen typischerweise auf die Analyse der Wertschöpfungskette bzw. Geschäftsprozesse – unabhängig ob inner- oder überbetrieblich – beschränkt.313 Für die Integration der Anwendungssysteme in Un311 312

313

Vgl. u. a. Nolte (1999), S. 8-9; Bayerlein (2005), S. 6; Staudt et al. (1992), S. 47-53. Vgl. etwa Morris/Jamieson (2005), S. 5-8; Loh/Koh (2004), 3441-3442; Nah et al. (2001), S. 291; Williams (1997), S. 187. Vgl. etwa Eckert et al. (2005), S. 667-668; Mantel et al. (2004), S. 24; Niemann et al. (2002), S.

130

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

ternehmensnetzwerken ist dieses Vorgehen aufgrund von zwei Aspekten nicht zwangsläufig möglich, die im Folgenden dargelegt werden. Zunächst sind die Wertschöpfungsstrukturen von Netzwerken im Detail zu beachten. Wie beschrieben findet abhängig von der Netzwerktypologie im Rahmen der Zusammenarbeit innerhalb des Netzwerks mitunter eine flexible Konfiguration der Netzwerkpartner zur Auftragsbearbeitung statt (vgl. Abb. 4.4.1.1/1).314

UB1

UB2

UB3

starre Konfiguration Aufträge des Auftragtyps n

P1

P2

P3

flexible Konfiguration Aufträge des Auftragtyps n UBn = Unternehmensbereich

Pn

= Netzwerkpartner

Abb. 4.4.1.1/1: Starre und flexible Konfiguration der Auftragsbearbeitung

Eine reine Analyse der Prozessketten, bei denen die Aufgaben in Form von einzelnen Prozessschritten sowie die entsprechenden Aufgabenträger ermittelt werden, ist nur bedingt hilfreich. Hintergrund dieser Annahme ist die Tatsache, dass sich durch ein solches Vorgehen vor allem die Konfigurationen der Vergangenheit berücksichtigen lassen. Nicht zwangsläufig zu erwarten ist allerdings, dass ein gleicher Auftragstyp des Netzwerks in der ermittelten Konfiguration ein weiteres Mal durchgeführt wird. Die auf diesem Weg identifizierten Integrationsbereiche würden dann nicht zwangsläufig den tatsächlichen Integrationsbereichen entsprechen.315 Zu berücksichtigen ist daher, inwiefern Partnerunternehmen bei zukünftigen Aufträgen eines Auftragstyps potenziell an der Durchführung beteiligt und dabei von Anwendungssystemen unterstützt werden, die integriert werden müssen. Folglich gilt es, die Analyse

314

315

426; Österle et al. (1991), S. 112; Petri (1990), S. 156-158. Im Rahmen der Grundlagen wurden diese Netzwerke als instabile Netzwerke bezeichnet. Ihr Kennzeichen lag in der auftragsspezifischen Konfiguration der am Auftrag beteiligten Partnerunternehmen (vgl. Kapitel 2.1.1.3 sowie Albers et al. (2003), S. 9; Schuh et al. (1998), S. 63). Vgl. Palanisamy (2005), S. 64-66.

Techniken

131

der Prozesse derart zu modifizieren, dass nicht nur Konstellationen der Vergangenheit, sondern auch mögliche Konstellationen der Zukunft berücksichtigt werden. Darüber hinaus wurde im Rahmen der Fallstudien ein weiterer zu beachtender Aspekt im Hinblick auf die Identifizierung von Integrationsbereichen aufgedeckt. Die Identifikation mittels der Prozessanalyse setzt die Existenz von Wertschöpfungsketten bzw. Prozessen voraus. Die Betrachtung der Fallstudien zum Integrationsvorgehen in Unternehmensnetzwerken offenbarte hingegen, dass bestehende Prozesse nicht zwangsläufig vorliegen müssen. Insbesondere für Netzwerke zu Beginn des Lebenszyklus und mit entsprechend geringer Kooperationserfahrung ist das Fehlen von sich häufig wiederholenden Prozessen wahrscheinlich.316 Unabhängig davon nimmt die Integration von Anwendungssystemen in dieser Phase des Lebenszyklus des Netzwerks eine hervorzuhebende Rolle ein. So ist gerade in der Phase der Netzwerkbildung die Schaffung einer effizienten Netzwerkinfrastruktur – was ebenfalls die technische Ausgestaltung betrifft – von Bedeutung und berührt damit unmittelbar die Integration von Anwendungssystemen.317 Ausgehend von den mitunter flexiblen Wertschöpfungsketten in Netzwerken ist ein Ansatz zu wählen, der trotz der beschriebenen Besonderheiten die Identifikation von Integrationsbereichen ermöglicht. Erreichen lässt sich dies, indem die Identifikation der Integrationsbereiche nicht direkt an Netzwerkprozessen ansetzt, sondern am übergeordneten Kooperationszweck und den sich daraus ergebenden Zielen des Netzwerks, um über diesen Weg auf die Ausgestaltungsvarianten des Netzwerks zu schließen.318 Entsprechend sind für die Identifikation der Integrationsbereiche zunächst die Ziele des Netzwerks zu ermitteln, aus denen wiederum die netzwerkspezifische Organisationsgestaltung abgeleitet wird. Demzufolge sind für die Ermittlung der Integrationsbereiche in Unternehmensnetzwerken in einem ersten Schritt zunächst der übergeordnete Kooperationszweck sowie die Netzwerkziele zu ermitteln. In einem weiteren Schritt gilt es schließlich die Netzwerkorganisationen abzuleiten, aus denen sich später die Integrationsbereiche ergeben. Wie beschrieben stellt die Identifizierung der Netzwerkziele den Ausgangspunkt zur Ermittlung der Netzwerkorganisation dar. Innerhalb der Netzwerkliteratur finden sich vielfältige Beiträge, die sich mit Netzwerkzielen auseinandersetzen.319 Weitgehend unbeantwortet bleibt dabei jedoch typischerweise die Frage, welches Vorgehen für

316

317 318

319

Der Lebenszyklus eines Netzwerks umfasst im Kern die Phasen Identifikation, Anbahnung, Gründung, operative Phase und Beendigung (vgl. etwa Staudt et al. (1992) S. 25-257; Faisst (1997), S. 5; Tschandl (2000), S. 78-84). Vgl. Becker (1999), S. 148-150. Vgl. Nolte (1999), S. 59. Vgl. Bleicher (1991), S. 35 für die aus Unternehmenszielen abgeleiteten Aufgaben als Aufforderungen zum wiederholten Handeln. Vgl. z. B. die Arbeiten von Bresser (1989); Gerpott/Böhm (2000); Schober/Raupp (2003).

132

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

die Zielermittlung und -formulierung in Netzwerken zu wählen ist. Nur vereinzelt finden sich Arbeiten, die diese Fragestellung beleuchten.320 Im Kern wird dabei das klassische Vorgehen zur Zielermittlung in Organisationen321 um netzwerkspezifische Besonderheiten erweitert. Die Zielerfassung in Netzwerken erfolgt im Wesentlichen durch eine gemeinschaftliche Definition des Netzwerkszwecks 322 und bildet die Grundlage für sämtliche Aktivitäten, die von den Partnern im Rahmen der Netzwerkarbeit übernommen werden. Die netzwerkspezifischen Besonderheiten im Rahmen der Zielbildung ergeben sich dabei aus der rechtlichen und wirtschaftlichen Selbstständigkeit der Partnerunternehmen.323 Aufgrund fehlender rechtlicher Weisung im Netzwerk muss bei der Zieldefinition eine weitgehende Übereinstimmung zwischen den Partnerunternehmen erreicht werden. Ohne diese kann es zu Netzwerkaustritten kommen, sofern einzelne Partnerunternehmen ihre individuellen Ziele nicht in den kollektiven Zielen wieder finden.324 Ausgehend von der Literatur des Zielbildungsprozesses anderer Organisationsformen lassen sich grundsätzlich zwei unterschiedliche Zugänge zur Zielfindung in Netzwerken unterscheiden:325 Zum einen sind die kollektiven Ziele durch eine vorzunehmende Auswahl von Einzelzielen aus bestehenden Zielkatalogen zu ermitteln. Entsprechend sind bei diesem „geschlossenen“ Ansatz die vereinbarten kollektiven Zieldefinitionen lediglich auf die Ziele beschränkt, die in den zur Auswahl hinzugezogenen Zielkatalogen enthalten sind. Zum anderen kann die Ermittlung der kollektiven Ziele über einen „offenen“ Zielbildungsansatz erfolgen. Die kollektive Zielfindung erfolgt dabei durch die gemeinsame Abstimmung zwischen den Netzwerkpartnern im Rahmen eines teilstrukturierten Ablaufs unter der Nutzung von Kreativtechniken.326 Die Beschränkung auf die enthaltenen Ziele der Zielkataloge lässt den ersten, geschlossenen Ansatz im Vergleich zum zweiten Zielfindungsansatz kurzfristig und mit einem geringen Ressourceneinsatz durchführen. Nachteile zeigen sich im Hinblick auf die ermittelten Ziele, die sich typischerweise lediglich auf die vorgegebenen, meist abstrakten Ziele der vordefinierten Zielkataloge beschränken. Dieser Nachteil

320 321 322 323 324

325 326

Vgl. etwa die Arbeit von Wohlgemuth (2002), S. 137-148; Stuhldreier/Ellerkmann (2000), S. 58-70. Vgl. etwa Nagel (1992) oder Daenzer/Huber (1999), S. 135-156. Vgl. Staudt et al. (1992), S. 47-49. Vgl. Kapitel 2.1.1. Grundsätzlich ist in Netzwerken davon auszugehen, dass die Partnerunternehmen unterschiedliche Ziele verfolgen. Im Rahmen der kollektiven Zieldefinition ist entsprechend nicht zu erwarten, dass sich im Netzwerk auf ein einzelnes Ziel geeinigt wird, sondern es ist vielmehr eine mehrdimensionale Zieldefinition anzutreffen (vgl. Wildemann (1998), S. 31-33; Hill et al. (1989), S. 153154). Vgl. Wohlgemuth (2002), S. 139-140. Vgl. u. a. Nagel (1992), Sp. 2633-2634; Hauschildt (1977), S. 23.

Techniken

133

ist der wesentliche Aspekt, der hier zur Auswahl des offenen Ansatzes für die Zielermittlung in Netzwerken führt. So gewährleistet er insbesondere die Ermittlung netzwerkspezifischer Ziele im Vergleich zu relativ unspezifischen und potenziell unvollständigen Netzwerkzielen aus bestehenden Zielkatalogen. Die aktiven Analyse- und Reflektionsprozesse im Rahmen des offenen Ansatzes erweitern darüber hinaus das Verständnis über das Netzwerk. Dies erleichtert die vertiefenden Analysen des Netzwerks im Rahmen der folgenden Schritte zur Ermittlung der Netzwerkorganisation. Der oben skizzierte geschlossene Ansatz in allgemeiner Form bedarf jedoch einer netzwerkspezifischen Erweiterung. Allgemein ist der Zielbildungsprozess durch die Phasen (1) Zielfindung, (2) Zielpräzisierung, (3) Zielbereinigung und schließlich (4) Zielauswahl gekennzeichnet.327 Im Rahmen der Zielfindung wird unter Zuhilfenahme von Kreativitätstechniken ein umfassender Zielkatalog aufgestellt. Darin gesammelt sind die obersten Ausgangsziele einer Organisation. Die Ziele des ermittelten Zielkatalogs werden in der zweiten Phase zur Präzisierung in Form einer hierarchischen Zielstruktur (Zielbaum) abgebildet. Somit erhält man aus den groben übergeordneten Zielen operationalisierte Ziele, für die sich konkrete Maßnahmen ableiten lassen. Zuvor findet jedoch in einem weiteren Schritt die Bearbeitung und Bereinigung der Ziele statt. Dieser Schritt zielt unter anderem auf die Aufdeckung von Konflikten und der Priorisierung ermittelter Ziele. Abgeschlossen wird der Zielbildungsprozess schließlich mit der Zielauswahl bzw. Zielentscheidung. Dabei wird in Form eines Entschlusses festgehalten, welche der identifizierten Ziele konkret von der Organisation verfolgt werden. Die allgemeinen Phasen der Zielformulierung lassen sich weitgehend für eine Anwendung auf Unternehmensnetzwerkebene übertragen. Im Kern ist dafür lediglich eine Anpassung nötig. Die Anpassung beruht auf der in Unternehmensnetzwerken nötigen Unterscheidung zwischen der Netzwerk- und der Partnerebene, verbunden mit der Berücksichtigung der Selbständigkeit von Netzwerkpartnern. Entsprechend den beiden Ebenen ist es nötig, die ermittelten Ziele auf der Netzwerkebene jeweils mit den individuellen Zielen der Netzwerkpartner abzustimmen, da es bei Missachtung der Ziele auf Partnerebene zu Netzwerkaustritten kommen kann. Wird der zuvor beschriebene Prozess der Zielformulierung betrachtet, kann die Abstimmung der Netzwerk- und Partnerziele nur nach der Zielbereinigung stattfinden, da sich das Netzwerk erst dabei auf eine erste Zielauswahl einigt (vgl. Abb. 4.4.1.1/2).

327

Vgl. hierzu und im Folgenden Bea et al. (2001), S. 50-52; Nagel (1992), Sp. 2633-2634; Lehner et al. (1991), S. 242-244.

134

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

1 allgemeiner Zielbildungsprozess

2 Zielpräzisierung

Zielfindung

1 angepasster Zielbildungsprozess für Netzwerke

3

2 Zielfindung

4 Zielbereinigung

3 Zielpräzisierung

Zielauswahl

5 Zielbereinigung

Zielauswahl

4 Abgleich der Partnerund Netzwerkziele

Abb. 4.4.1.1/2: Schritte im Zielbildungsprozess

Ausgehend von den verabschiedeten Zielen ist die organisatorische Ausgestaltung des Netzwerks zu ermitteln. Innerhalb der Betriebswirtschaftslehre ist für diese Fragestellung der Ansatz der Aufgabenanalyse und -synthese verbreitet, der sich ebenfalls für den Einsatz in Netzwerken eignet.328 Ausgehend von den Zielen liegt das grundlegende Vorgehen dieses Ansatzes in der Gliederung von Aufgaben in ihre elementaren Bestandteile. Deren anschließende Bündelung zu sinnvollen Aufgabenpaketen329 sind schließlich Stellen zuzuordnen, welche die Aufgabenpakete übernehmen können. Demzufolge wird das Vorgehen insbesondere zur Ermittlung der Aufbauorganisation vorgeschlagen. An diesem innerhalb der Organisationstheorie stark verbreiteten Ansatz wird allerdings schon seit geraumer Zeit die konzeptionelle Trennung der Organisationsstruktur von Prozessen der Organisation als problematisch angesehen.330 Grund dafür ist die gegenseitige Bedingung der Aufbau- und Ablauforganisation, die eine unabhängige Optimierung der beiden Gestaltungsfelder ausschließt. Lösungsansätze zu dieser Problematik finden sich in den Arbeiten zu Prozessorganisationen.331 Innerhalb dieser findet sich keine Trennung zwischen der Aufbau- und Ablauforganisation. Vielmehr gehen diese Lösungsansätze grundsätzlich von einem strukturierten Arbeitsablauf aus, bei dem die Struktur und der Prozess gleichermaßen betrachtet werden. Für die Aufgabenanalyse beinhalten diese Lösungsansätze, dass die Zerlegung der Gesamtaufgabe nach Prozessen erfolgt, die als ganzheitliche Arbeitsein328

329

330 331

Vgl. Picot et al. (2005), S. 228-230 sowie im Original Kosiol (1968), S. 29-75. Für einen netzwerkspezifischen Einsatz vgl. Hess (2002a), S. 152-158. Sinnvoll ist ein Aufgabenpaket vor allem dann gebündelt, wenn es möglichst wenige Schnittstellen zu anderen Aufgabenpaketen hat. Vgl. zur Diskussion etwa Gaitanides (1983), S. 53-59; Picot/Franck (1995), S. 16-18. Vgl. etwa die Arbeiten von Hammer/Champy (1994); Davenport (1993).

Techniken

135

heiten oder Tätigkeitsfolgen verstanden werden.332 In Anlehnung an die Aufgabenanalyse lassen sich die Prozesse ebenfalls untergliedern – typisch ist die Gliederung in Teilprozesse, Prozess- und Arbeitsschritte – und möglichen Aufgabenträgern zuordnen.333 Grundsätzlich lässt sich die Gliederung ebenfalls auf Unternehmensnetzwerke übertragen. Modifikationen des Ansatzes sind jedoch bei der Zuordnung der Teilprozesse zu den Aufgabenträgern zu beachten. Innerhalb von Unternehmensnetzwerken werden diese nicht von einzelnen Personen oder Unternehmensbereichen dargestellt, sondern durch die Netzwerkpartner In Betracht gezogen werden muss, dass in Netzwerken häufig mehrere Partnerunternehmen zur Übernahme der Teilprozesse infrage kommen. Dies ist etwa der Fall, wenn die Verteilung der Teilprozesse innerhalb des Netzwerks nicht im Vorhinein definiert ist, wie beispielsweise durch spezifische Kompetenzen der Netzwerkpartner. Bei der Zuordnung der Teilprozesse zu den Partnerunternehmen sind somit sämtliche Netzwerkpartner zu berücksichtigen, die zur Übernahme infrage kommen (vgl. Abb. 4.4.1.1/3). Eine Festlegung auf ein einziges Partnerunternehmen als Aufgabenträger würde hingegen die Möglichkeit unterschiedlicher Konfiguration des Netzwerks bei der Auftragserfüllung ausschließen.334 Vergleichbar ist dieses Vorgehen mit der Ermittlung des Kompetenzkatalogs eines Netzwerks.335 Ein Kompetenzkatalog hält durch die Erfassung der Kompetenzen ebenfalls Netzwerkpartner fest, die potenziell einen Teilauftrag übernehmen können, ohne sämtliche Teilaufträge fest zu vergeben. Die tatsächliche Vergabe – etwa durch interne Märkte – ist somit nicht zwangsläufig Gegenstand der Ermittlung von Integrationsbereichen. Sie findet vielmehr bei der konkreten Aufgabenspezifizierung auf leistungsbezogener Ebene des Netzwerks statt.336

332 333 334 335 336

Vgl. Schreyögg (2003), S. 121. Vgl. Schmelzer/Sesselmann (2006), S. 109-111 sowie 123-124. Vgl. Ringlstetter (1997), S. 70-71. Vgl. Wittenberg (2004), S. 60-68. Vgl. Hess (2002a), S. 157-177.

136

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Synthese

Analyse

Teilprozess AI

Netzwerkpartner A

Teilprozess AII

Netzwerkpartner B

Geschäftsprozess A

Zielsetzung

Teilprozess nI Geschäftsprozess n Teilprozess nII

Netzwerkpartner n

zur Übernahme von Teilprozessen in Frage kommende Netzwerkpartner

Abb. 4.4.1.1/3: Angepasstes Analyse-Synthese-Schema

4.4.1.2

Vorgehen

Das im Folgenden vorgestellte Vorgehen zur Ermittlung der Netzwerkorganisation verbindet den oben beschrieben Prozess der Zielbildung in Netzwerken mit der ebenfalls skizzierten Ermittlung des Netzwerkaufbaus sowie den entsprechenden Abläufen. Das Vorgehen umfasst sechs Schritte: Die ersten vier Schritte der Technik zielen dabei auf die Ermittlung der Netzwerkziele. Dabei ist im Vergleich zu dem oben beschriebenen Ansatz eines Zielbildungsprozesses in Netzwerken die Phase der Zielfindung und Präzisierung in einem Schritt zusammengefasst. Im Anschluss erfolgt die Zielbereinigung bei der zunächst konfliktäre Ziele aufgedeckt werden und schließlich eine Zielpriorisierung auf Netzwerkebene vorzunehmen ist. Daraufhin folgt ein individueller Zielabgleich mit den Zielen auf Partnerebene, eine eventuelle Zielkorrektur sowie die Zielverabschiedung. Nach der Zielverabschiedung ist die Netzwerkorganisation zu ermitteln. Dazu sind im fünften Schritt der Technik Netzwerkprozesse zu analysieren und daraus im abschließenden sechsten Schritt die Netzwerkprozessorganisation abzuleiten (vgl. Abb. 4.4.2.2/1).

Techniken

137

nötige Input-Dokumente

erhaltene Ergebnisdokumente

Vorgehen 1.

Ermittlung der Netzwerkziele

2.

Bereinigung der Netzwerkziele

3.

individueller Zielabgleich auf Partnerebene

4. keine

Zielkorrekturen und -verabschiedung

5.

Analyse der Netzwerkprozesse

6.

Ableitung der Netzwerkprozessorganisation

•

Zielverabschiedung

•

Prozessübersicht

•

Prozessorganisationsdiagramm

Abb. 4.4.1.2/1: Vorgehensschritte und Ergebnisdokumente zur Ableitung der Netzwerkprozessorganisation

Schritt 1: Ermittlung der Netzwerkziele Ausgangspunkt des Zielbildungsprozesses in Netzwerken ist die Schaffung eines einheitlichen Verständnisses über den Inhalt sowie den Zweck der Kooperation. Dazu sollte die Gesamtheit aller angestrebten wirtschaftlichen Aktivitäten der Kooperation erfasst werden.337 Im Kern ist die Frage nach dem Auftrag der Kooperation zu beleuchten. Hilfestellung leistet bei der Ermittlung des Kooperationszwecks die Analyse der folgenden Einflussfaktoren.338 Diese umfassen die (1) Netzwerkposition, die durch die Rolle des Netzwerks innerhalb der anvisierten Märkte sowie Branchen charakterisiert wird. Ausgehend von der angestrebten Positionierung ist die Betrachtung der (2) Netzwerkbetätigung vorzunehmen. Diese zielt auf die Ermittlung besonderer Kompetenzen bzw. hervorzuhebender Technologien des Netzwerks sowie auf die damit zu erstellenden Leistungen und deren anvisierte Abnehmer ab. Daneben sind die (3) Potenziale und Restriktionen des Netzwerks zu ermitteln. Im Hinblick auf die Potenziale ist zu klären, inwiefern Unternehmensressourcen bestehen, um die angestrebte Positionierung zu erreichen. Die Ermittlung der Restriktionen zielt hingegen auf die Analyse möglicher fehlender Ressourcen ab. Schließlich ist die (4) Grundhaltung des Netzwerks und damit die Eckpunkte der Netzwerkpolitik zu ermitteln, wie etwa die angestrebte Kundenorientierung oder das Qualitätsniveau. Im Rahmen der Zielpräzisierung sind ausgehend vom allgemeinen Kooperationszweck die übergeordneten Sachziele des Netzwerks zu ermitteln.339 Dabei werden die globalen Zielvorstellungen des Netzwerks auf auftragsübergreifender Ebene be337 338 339

Vgl. Hamel (1992), Sp. 2637. Vgl. hierzu und im Folgenden Staudt et al. (1992), S. 47-48. In der klassischen Terminologie der Betriebswirtschaftslehre wird zwischen Sach- und Formalzielen unterschieden. Erstere beschreiben das sachliche Leistungsprogramm, auf das sich sämtliche unternehmerischen Tätigkeiten ausrichten. Letztere definieren hingegen qualifizierende Merkmale, die sich zur Beurteilung der Zielerreichung heranziehen lassen (vgl. etwa Hamel (1992), Sp. 26382639).

138

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

stimmt, die möglichst über die vollständige Kooperationsdauer Bestand haben. Entsprechend wäre ein typisches Beispiel für ein Leitziel einer Kooperation im Luftverkehr die Gewinnung von Geschäftskunden auf interkontinentalen Flugrouten. Mittels Kreativtechniken erfolgt die Ermittlung der Sachziele des Netzwerks. Ausgangspunkt der Ermittlung bildet die Frage, was die Netzwerkpartner durch die Kooperation erreichen und was sie vermeiden wollen. Dazu sind die Zieläußerungen zu sammeln und bei Bedarf um individuelle Interessen der Netzwerkpartner zu ergänzen.340

Schritt 2: Bereinigung der Netzwerkziele Die Sammlung und Präzisierung der Ziele führt typischerweise zu einem komplexen Zielkatalog. Dieser kennzeichnet sich in der Regel durch konkurrierende oder fehlende Ziele sowie durch enthaltene Ziele unterschiedlicher Relevanz für das Netzwerk. Im Rahmen der Zielbereinigung erfolgt deshalb eine systematische Analyse und Strukturierung der gesammelten Ziele. Das Vorgehen dazu ist angelehnt an die innerhalb der Zielforschung verbreiteten Grundsätze der Zielformulierung.341 Deren Berücksichtigung gewährleistet unter anderem, dass die Ziele des Netzwerks (1) in ihrer Vollständigkeit erfasst sowie (2) lösungsneutral sind, (3) nicht in Konkurrenz zueinander stehen und (4) auf eine überschaubare Anzahl beschränkt bleiben. Vollständig sind die Ziele ermittelt, wenn sämtliche Aspekte der Kooperation bei der Zielsammlung berücksichtigt wurden. Unterstützen lässt sich die Vollständigkeit der gesammelten Ziele durch die Berücksichtigung dreier Blickwinkel auf die Kooperation.342 Dazu ist die Kooperation zunächst inhaltlich zu betrachten und im Hinblick auf sich daraus ergebende Ziele zu analysieren. Als Anhaltspunkte für diese inhaltliche Betrachtung lassen sich die bereits im ersten Schritt verwendeten Einflussfaktoren wie Positionierung, Betätigungsfeld, Potenziale und Restriktionen sowie Grundhaltung des Netzwerks heranziehen. Darüber hinaus erfolgt die Sicherstellung der Zielvollständigkeit durch eine interessenbezogene Netzwerkanalyse und sich daraus ableitende Ziele. Dabei sind die Ziele unter Berücksichtigung der Netzwerkpartner und des Netzwerkumfelds wie Lieferanten, Kunden und Konkurrenten zu ermitteln. Schließlich sind bei der Zielermittlung erkennbare Mängel des Netzwerks zu hinterfragen und auf sich daraus ergebende Ziele zu untersuchen. Neben der Vollständigkeit ist im Rahmen der Zielbereinigung eine ausreichende Lösungsneutralität der ermittelten Ziele zu erreichen. Die Lösungsneutralität von Zielen

340

341

342

Vgl. etwa Hill et al. (1989), S. 152-154. Für gängige Kreativtechniken vgl. Jung (2004), S. 594; Burghardt (2002), S. 570-576. Für Grundsätze der Zielformulierung vgl. etwa Mag (1995), S. 54-56; Nagel (1992), Sp. 26292633. Vgl. Nagel (1992), Sp. 2631.

Techniken

139

verhindert, dass der Lösungsraum bereits während der Zielsuche eingeschränkt wird. Möglich ist dies, indem eine in stärkerem Ausmaß auf die Wirkung der Ziele ausgerichtete Beschreibung angestrebt wird. Die Ermittlung unterschiedlicher Ziele führt wie beschrieben typischerweise dazu, dass der Zielkatalog an Komplexität gewinnt und zueinander unvereinbar stehende Ziele enthält. Die Gewichtung bzw. Priorisierung ermöglicht ein rationales Handeln trotz umfangreicher und teilweise konkurrierender Zielsysteme. Unter Zuhilfenahme von Zielrelationsmatrizen lässt sich die Zielbeziehung aufdecken.343 Dazu sind die Ziele in Matrizenform gegenüberzustellen und vom Netzwerk im Hinblick auf ihre Verträglichkeit zu beurteilen. Dies geschieht durch die Vergabe von Bewertungsziffern (vgl. Abb. 4.4.1.2/2).

Ziele

Ziele

0 1 1

2

0

0

1

2

0

2 0

Zielrelationsbeurteilung des Ziels i (ZRi)

1

2 = Ziele der Zeile u. Spalte unterstützen sich 1 = Ziele der Zeile u. Spalte beeinflussen sich nicht 0 = Ziele der Zeile u. Spalte stehen im Konflikt

Abb. 4.4.1.2/2: Zielrelationsmatrix zur Ermittlung der Zielverträglichkeit

Nach der Beurteilung der Zielbeziehung sind die Ziele jeweils von den einzelnen Partnern des Netzwerks zu priorisieren.344 Die Beurteilung der Zielrelevanz ist ebenfalls in Form von Matrizen zu erfassen. Ermittelt wird dabei, inwiefern die Ziele der Spalten wichtiger, gleich wichtig oder weniger wichtig als die Ziele der Zeilen sind. Die Zusammenfassung der einzelnen Einschätzungen der Partnerunternehmen lässt die Zielrangfolge ermitteln (vgl. Abb. 4.4.1.2/3). Durch eine zusätzliche Erfassung der Standardabweichung lassen sich darüber hinaus “Ausreißer“ aufdecken und ihr Zustandekommen anhand der Einzelbewertungen erörtern. 343

344

Drei unterschiedliche Zielbeziehungen sind zu unterscheiden. Bei komplementären Zielen führt eine verbesserte Erreichung des Ziels z1 ebenfalls zu einer verbesserten Erreichung des Ziels z2. Bei konkurrierenden Zielen führt hingegen eine verbesserte Zielereichung des Ziels z1 zu einer verschlechterten Erreichung des Ziels z2. Schließlich besteht bei indifferenten Zielen kein kausaler Zusammenhang zwischen den Zielen z1 und z2 (vgl. Wöhe (2002), S. 99-100). Dies kann unter Verwendung einer dreistufigen Bewertungsskala erfolgen bei der eine „0“ für Ziele mit geringer, eine „1“ für Ziele mit gleich wichtiger und eine „2“ für Ziele mit einer hohen Wichtigkeit vergeben werden.

140

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Partner: n Beurteilung:

2

Ziele der Zeile u. Spalte stehen im Konflikt

1

Ziele

1

2 2 0

1 2 1

1 12 1

Ziele (...)

12

2 (...) (...)8 12 20 1 2

2 (...)

(...)

12

0

(...)

8

8

Ergebnisblatt

1

Relevanzbewertung der Partner

Mittelwert

Ziele

Standardabweichung

0

Partner: Ziele A

Ziele

0

Partner: B

Ziele der Zeile u. Spalte unterstützen sich Beurteilung: Ziel der Zeile u. Spalte 2 Ziele dersich Zeile u. Spalte beeinflussen nicht unterstützen sich Beurteilung: Ziele der Zeile u. Spalte 1 Ziel Zeile u. Spalte stehen imder Konflikt 2 Ziele der beeinflussen sichZeile nichtu. Spalte unterstützen sich 0 Ziele der Zeile u. Spalte 1 im Ziele der Zeile u. Spalte stehen Konflikt beeinflussen sich nicht

Punktsumme

2 1

12

9

(...)

11,2

1,4

8

7

(...)

9,8

1,6

5

2

Zielgewichtung des Ziels i (Gi)

Abb. 4.4.1.2/3: Relevanzbeurteilung der Ziele345

Zum Abschluss der Bereinigung werden für die zusammenfassende Zielpriorisierung sowohl die ermittelten Zielbeziehungen als auch die Relevanzbeurteilungen hinzugezogen. Dazu werden jeweils die Mittelwerte aus dem Ergebnisblatt als Zielgewichtungen Gj mit den entsprechenden Zielrelationsbeurteilungen der Ziele (ZRi) multipliziert und zeilenweise addiert. Damit fließt zum einen die kumulierte Bedeutung der Ziele für die Netzwerkpartner sowie die Zielverträglichkeit aus der Zielrelationsbeurteilung in die Priorisierung mit ein.346 Ergebnis der Berechnung ist die Zielunterstützung (ZU) für jedes Einzelziel i, wobei j die Zeile der Zielrelationsmatrix bezeichnet und n die Anzahl der Ziele (vgl. Abbildung 4.4.1.2/4).

ZU i

n

¦G j 1

j

˜ ZRij

Abb. 4.4.1.2/4: Rangordnungssumme zur Ermittlung der Zielgesamtunterstützung347

Schritt 3: Individueller Abgleich zwischen Unternehmens- und Netzwerkzielen Innerhalb des dritten Schritts überprüfen die Partnerunternehmen, inwiefern sich die eigenen Ziele im Hinblick auf die Kooperation mit den ermittelten Netzwerkzielen vereinen lassen. Im Kern sind dazu die ersten beiden Schritte des Zielbildungsprozesses zu wiederholen, wobei nun jedoch anstelle der Unternehmenssicht die Netz345 346

347

In Anlehnung an Wohlgemuth (2002), S. 144. Entsprechend erhalten die Ziele, die häufig in Konflikt mit anderen Zielen stehen, eine systematisch schlechtere Bewertung als Ziele, die andere Ziele laut der Zielrelationsmatrix unterstützen. Ähnlich Heinrich (2002), S. 431.

Techniken

141

werkperspektive einzunehmen ist. Nach der Erfassung und Priorisierung der Unternehmensziele sollten diese den zuvor ermittelten Zielen des Netzwerks – etwa in Form von Matrizen – gegenübergestellt werden.348 Werden die Kooperationsabsichten eines einzelnen Partnerunternehmens auf Netzwerkebene nur geringfügig berücksichtigt, so sollte der Netzwerkpartner einen möglichen Kooperationsaustritt prüfen. Finden hingegen im Rahmen der Kooperationsziele nur vereinzelt Partnerziele keine Berücksichtigung, so bedarf es einer Erwägung auf Seiten des entsprechenden Netzwerkpartners, ob die eigenen Ziele von solch übergeordneter Bedeutung sind, dass sie sich keinesfalls zurückstellen lassen.

Schritt 4: Erörterung von Korrekturen und Verabschiedung des gemeinsamen Zielsystems Durch den Zielabgleich auf Partnerebene kann es zu Änderungs- und Erweiterungswünschen der Netzwerkpartner kommen, die vor der Verabschiedung der Ziele zu klären sind. Drei Varianten stehen zur Verfügung, um auftretende gegensätzliche Zielansichten aufzulösen.349 Die Möglichkeiten umfassen die (1) einseitige Zielreduktion/-aufgabe, die (2) zweiseitige Zielreduktion (Kompromiss) sowie das (3) Problemlösen. Die Schlichtung, die Ausübung von Macht oder die Einsicht über unrealistische Ziele sind typische Verhaltensmuster, die zu einer einseitigen Zielreduktion/aufgabe führen. Im Rahmen des Zielbildungsprozesses in Unternehmensnetzwerken ist insbesondere eine einseitige Zielaufgabe in fokal gesteuerten Netzwerken zu erwarten, wenn der zentrale Partner seine dominierende Rolle ausnutzt. Durch die Reduzierung von Zielausmaßen lassen sich konfliktäre Zielansichten im Sinne einer Kompromisslösung auflösen. Zu erwarten ist diese Verhaltensweise zur Beseitigung gegensätzlicher Ziele speziell für polyzentrische Netzwerke, da die Kompromissfindung eine gegenseitige, „demokratische“ Reduzierung der zuvor erhobenen Ansprüche erfordert.350 Das Problemlösen als dritte Konflikthandhabungsstrategie zielt schließlich auf die Suche nach neuen Alternativen, die bestehende Zielkonflikte auflösen. Entsprechend wären vor dem Hintergrund der bestehenden Konflikte innerhalb des Netzwerks die Schritte zwei bis fünf zu wiederholen, bis unter allen Beteiligten Einigkeit über die auszuwählenden Strategien herrscht.

348

349 350

Im Anschluss an die Bewertung im vierten Schritt bietet sich dazu die Vergabe von Bewertungsziffern an. Die Vergabe einer „2“ bedeutet etwa, dass ein Ziel auf Partner- und Netzwerkebene identisch ist. Eine „-2“ wird hingegen bei konkurrierenden Zielen vergeben und eine „-1“ bei Zielen, die im Zielsystem des Verbundes nicht berücksichtigt wurden (vgl. Wohlgemuth (2002), S. 145). Vgl. hierzu und im Folgenden Krüger (1980), S. 35-36. Vgl. Krüger (1980), S. 35.

142

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Zum Abschluss des Zielbildungsprozesses sollte das Netzwerk die ermittelten Ziele in formaler Form verabschieden.351

Schritt 5: Analyse der Netzwerkprozesse Zur Analyse sind zunächst die relevanten Netzwerkprozesse zu identifizieren. Ausgangspunkt der Identifikation bilden die Ziele des Netzwerks.352 Vor deren Hintergrund ist zu ermitteln, welche Prozesse zur Zielerfüllung beitragen.353 Von Bedeutung sind dabei insbesondere die kritischen Prozesse und damit solche, die einen wesentlichen Beitrag zur Zielerreichung leisten. Erleichtern lässt sich die Identifikation der relevanten Prozesse durch eine gesonderte Betrachtung von (1) Leistungsprozessen, die entsprechend zur Wertschöpfung des Netzwerks beitragen, (2) Führungsprozessen, die die Steuerung des Netzwerks betreffen sowie (3) Unterstützungsprozesse, die dem Aufbau und der Pflege der Ressourcen des Netzwerks sowie dessen Leistungsangebot dienen.354 Es sind lediglich die ermittelten Prozesse zu sammeln und anschließend hinsichtlich ihrer Bedeutung für die Zielerreichung und die Relevanz der Integration zu überprüfen. Drei Gestaltungsregeln gilt es bei der Sammlung der Geschäftsprozesse zu berücksichtigen:355 Zum einen sind die (1) Anfangs- und Endpunkte sämtlicher Prozessen zu definieren. Typischerweise finden sich die Punkte jeweils bei externen oder internen Kunden des Netzwerks.356 Darüber hinaus gilt es die (2) Prozessobjekte zu ermitteln. Ein Prozessobjekt ist der Gegenstand, welcher konkret von einem Prozess bearbeitet wird. Daher ist er vom Output eines Prozesses insofern zu unterscheiden, als dass der Prozessoutput (beispielsweise geliefertes Produkt oder installiertes System) das Ergebnis der Bearbeitung eines Prozessobjekts ist (beispielsweise ein Kundenauftrag).357 Schließlich sind die (3) Inputs festzuhalten, die ein Prozess benötigt, sowie die Outputs bzw. Leistungen, die er erstellt. Ergebnis der Identifikation der Prozesse ist entsprechend eine Prozessübersicht, in der neben den Prozessen die Anfangs- und Endpunkte, Geschäftsobjekte sowie In- und Outputs verzeichnet sind.

351 352 353

354 355 356

357

Vgl. Wohlgemuth (2002), S. 146. Vgl. etwa Corsten (1997), S. 26. Vgl. etwa Schreyögg (2003), S. 122; Gaitanides et al. (1994), S. 6-7. Siehe für das Vorgehen im Rahmen von Anwendungssystemprojekten IBM (1984), S. 9; Batiste/Jung (1984), S. 217. Vgl. Hess (1996), S. 167-173. Vgl. Schmelzer/Sesselmann (2006), S. 396; Best/Weth (2005), S. 56. Interne Kunden gibt es bei Organisationsformen, innerhalb derer – wie bei Unternehmensnetzwerken – marktähnliche Strukturen bestehen, jedoch keine eigentlichen Geschäfte abgewickelt werden (vgl. Krüger (1994), S. 121). Vgl. Schmelzer/Sesselmann (2006), S. 112-113.

Techniken

143

Im Anschluss an die Sammlung sind die Prozesse im Hinblick auf Ihre Relevanz für die Integration von Anwendungssystemen zu untersuchen. Die Beurteilung erfolgt dabei anhand zweier Kriterien.358 Zum einen ist zu ermitteln, inwiefern die gesammelten Prozesse einen Beitrag zur Unterstützung der Netzwerkziele leisten. Darüber hinaus ist zu klären, inwiefern eine Anwendungssystemintegration für die ermittelten Prozesse von Bedeutung erscheint. Wie bereits bei der Beurteilung der Ziele erfolgt die Einschätzung der Prozesse durch die jeweiligen Netzwerkpartner, die im Anschluss zu einer Gesamteinschätzung des Netzwerks konsolidiert und durch die Partnerunternehmen zu verabschieden ist (vgl. Abb. 4.4.1.2/5). Partner: n Beurteilung:

erwarteter Beitrag zur Zielerreichung

geringe Erwartung

hoch

Integrationspotenzial

0

Beitrag zur Zielerreichung

2 hohen Partner: B Erwartung Beurteilung: 1 mittlere 2 hohen Partner: A Erwartung Erwartung 0 geringe Beurteilung: 1 mittlere Erwartung 2 hohe Erwartung Erwartung 0 geringe 1 mittlere Erwartung Erwartung

gering

Prozesse

gering

hoch

erwartetes Integrationspotenzial

Abb. 4.4.1.2/5: Beurteilung der Prozessrelevanz

Im Anschluss an die Sammlung der Prozesse erfolgt ihre Untergliederung. Typisch ist dabei die Strukturierung in aufeinander aufbauende Prozesskomponenten wie Teilprozess, Prozessschritt und Aktivität. Ausgangspunkt der Gliederung ist die Frage nach den Teilprozessen, aus denen sich ein Prozess zusammensetzt, wobei ein Prozess typischerweise in fünf bis acht Teilprozesse unterteilt wird. Die Gliederungsprinzipien Zerlegung, Ausgliederung und Gruppierung helfen bei der Dekomposition der Prozesse in die jeweiligen Prozessbestandteile:359 Im Rahmen der (1) Zerlegung richtet sich die Prozessgliederung nach den unterschiedlichen Verrichtungen, die beim Prozessdurchlauf anfallen. Die Dekomposition der Prozesse anhand des Prinzips (2) Ausgliederung erfolgt unter der Weitergabe von vertikalen Teil-

358 359

Ähnlich Gerpott/Wittkemper (1995), S. 152. Vgl. Gaitanides (1983), S. 75-76.

144

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

prozessen zum Zweck der arbeitsteiligen Erfüllung.360 Bei der (3) Gruppierung als Prinzip der Prozessstrukturierung werden schließlich Teilprozesse anhand bestimmter Kriterien voneinander abgegrenzt, wie etwa nach den vom Teilprozess betroffenen betrieblichen Funktionen.361 Die Tiefe der Prozessstrukturierung ist abhängig vom jeweiligen Netzwerk. Sie ist allerdings mindestens so weit vorzunehmen, dass bei der Übernahme der Komponente lediglich ein Partnerunternehmen dafür verantwortlich ist. Nicht von Bedeutung ist dabei die Frage, inwiefern unterschiedliche Partner potenziell für die Übernahme der strukturierten Prozesskomponente infrage kommen.

Schritt 6: Ableitung der Netzwerkprozessorganisation Anhand der ermittelten Prozesskomponenten wird schließlich die Netzwerkorganisation aufgestellt. Dazu wird der Prozessablauf der organisatorischen Ausgestaltung des Netzwerks gegenübergestellt. Dies erfolgt in Form eines Prozess-OrganisationsDiagramms, das für sämtliche der identifizierten Netzwerkprozesse erstellt wird.362 Das Diagramm lehnt sich an Funktionsdiagramme an, die im Rahmen des AnalyseSynthese-Schemas verbreitet sind. Im Kern zielen Funktionsdiagramme auf die Ermittlung der Zusammenhänge zwischen den Aufgabenträgern und den Aufgaben ab.363 Dazu sind die ermittelten Aufgaben sämtlich möglicher Aufgabenträger einander gegenüberzustellen und anhand der Funktionen zu bewerten, die ein Aufgabenträger im Hinblick auf die jeweilige Aufgabe übernimmt. Für die Übertragung der Diagramme auf die Ermittlung der Netzwerkprozessorganisation sind die ermittelten Prozesskomponenten zunächst für jeden Prozess in ihre logische Ablauffolge zu bringen. Im Anschluss werden den Komponenten eines Prozesses den Partnerunternehmen des Netzwerks gegenübergestellt. Verzeichnet ist dabei im Diagramm, inwiefern die Partnerunternehmen an der Leistungserstellung einer Prozesskomponente beteiligt bzw. verantwortlich sind (vgl. Abb. 4.4.1.2/6). Sind in einem Netzwerk Partnerunternehmen vertreten, die über eine Vielzahl von Fachbereichen verfügen, so kann dies ebenfalls im Diagramm abgebildet werden.

360

361

362 363

Beispielsweise erfolgt dies bei der Ausgliederung von Teilprozessen der vertikalen Planungs-, Koordinations- und Kontrollprozesse. Vergleichbar ist dieses Vorgehen mit der Gliederung nach Rang (beispielsweise Entscheiden oder Ausführen) und Phase (beispielsweise Planen oder Ausführen) aus der klassischen Aufgabenanalyse (vgl. etwa Nolte (1999), S. 60-62). Beispielsweise ist der Entwurf einer Landkarte in die Teilprozesse „Darstellung von Gebäuden und Verkehrswegen“, „Darstellung von Waldflächen und Höhenlinien“ sowie die „Darstellung von Gebirgs- und Wasserläufen“ durch die Gruppierung der Kriterien Gebäude und Verkehrswege usw. unterteilt (vgl. Berg (1981), S. 72). Vgl. Schmelzer/Sesselmann (2006), S. 123-124. Vgl. etwa REFA (1985), S. 46-52.

Techniken

145

Dazu ist die Spalte der Netzwerkpartner zu unterteilen und um die jeweiligen Fachbereiche der Netzwerkpartner zu ergänzen. Netzwerkpartner Partner 1 Partner 2 Partner 3 ... Partner n

Prozesskomponenten

Prozesskomponente 1

Prozesskomponente 2

...

Prozesskomponente n

verantwortlich beteiligt

Abb. 4.4.1.2/6: Netzwerkprozess-Organisations-Diagramm364

4.4.2 Identifikation der Integrationsbereiche Die im Folgenden vorgestellte Technik zur Identifikation der Integrationsbereiche innerhalb des Netzwerks schließt unmittelbar an die in der vorherigen Phase ermittelte Netzwerkprozessorganisation an. Zwei Integrationsbereichstypen sollen durch die Technik identifiziert werden. Zum einen sind die Integrationsbereiche aufgrund einer geringfügigen Anwendungssystemunterstützung des Prozesses sowie zum anderen zwischen bestehenden Anwendungssystemen aufzudecken. 4.4.2.1

Ansatz

Ausgehend von den übergeordneten Zielen wurde im bisherigen Methodenverlauf die Prozessorganisation des Netzwerks abgeleitet. Anhand dieser gilt es nun die Integrationsbereiche innerhalb des Netzwerks zu bestimmen. Grundsätzlich kennzeichnet ein Integrationsbereich eine fehlende Automatisierung von Informationsflüssen innerhalb und zwischen Prozessen.365 Für Unternehmensnetzwerke sind zwei

364 365

In Anlehnung an Schmelzer/Sesselmann (2006), S. 124. Vgl. Mertens (2004), S. 9; Fischer (1999), S. 153-158; Scheckenbach (1997), S. 9; Hilbers (1992), S. 159; Treuling (1990), S. 44-45.

146

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Integrationsbereichstypen relevant, die sich aufgrund einer bestehenden bzw. fehlenden Anwendungssystemunterstützung der Prozesse ergeben.366 Zum einen findet sich im Netzwerk eine Reihe Prozessschritte, bei denen die Informationsverarbeitung umfangreich durch Anwendungssysteme unterstützt wird. Integrationsbereiche ergeben sich bei diesen Prozessen, wenn der Informationsfluss zwischen zwei am Prozess beteiligten Anwendungssystemen unterbrochen ist. Typischerweise ist dies aufgrund fehlender Schnittstellen der am Prozess beteiligten Anwendungssysteme der Fall. Die Integration zielt in diesem Fall auf die Optimierung des Informationsflusses eines Prozesses durch die Verknüpfung der daran beteiligten Anwendungssysteme und der dadurch entstehenden Eliminierung bestehender Medienbrüche.367 Geschlossen werden diese Integrationsbereiche typischerweise durch die Architekturen der Applikations-Kommunikation bzw. des Daten-Sharings. Diese zielen auf die Nutzung der bisher bestehenden Anwendungssysteme bei einer Optimierung der zwischenbetrieblichen Informationsflüsse ab. Darüber hinaus finden sich in Netzwerken Prozesse und damit Informationsflüsse, die derzeit nicht bzw. kaum durch Anwendungssysteme unterstützt werden. Im Vergleich zur Integration in einem Einzelunternehmen ist dieser Fall bei Netzwerken nicht untypisch, da insbesondere in frühen Phasen des Netzwerklebenszyklus neue Prozesse entstehen. Dazu gehört etwa die Bildung und Vergabe von Teilaufträgen, für die bisher keine spezifischen Anwendungssysteme eingesetzt werden.368 Die Optimierung der entsprechenden Informationsflüsse erfolgt bei dieser Integrationsform durch den Einsatz eines integrierten Anwendungssystems, in dem möglichst sämtliche informationsverarbeitende Funktionen eines Prozesses integriert sind. Aufgedeckt werden diese Integrationsbereiche durch die Erfassung der Prozesse im Netzwerk, denen eine weitgehende Unterstützung durch Anwendungssysteme fehlt. Geschlossen werden sie typischerweise in Form einer ex-ante Integration, bei der eine dem Applikations-Sharing zugehörige Integrationsarchitektur die vollständige Informationsverarbeitung eines Prozesses abdeckt.369 Die Methoden des Integrationsmanagements enthalten allgemeine Hinweise zur Identifikation der Integrationsbereiche. Wie beschrieben erfolgt die Identifikation im Kern durch die Aufdeckung der Interdependenzen im Hinblick auf die Informationsverarbeitung, die den Geschäftsprozessen zugrunde liegt.370 Das Vorgehen dazu ist in drei Schritte zu unterteilen: Ausgehend von den Geschäftsprozessen sind in einem 366

367 368 369 370

Vgl. Schönherr/Gallas (2003), S. 128-129; Kaib (2002), S. 20-21; Kurbel/Rautenstrauch (1996), S. 169. Vgl. Schräder (1996), S. 110-118. Vgl. Mertens et al. (1998), S. 93-116. Vgl. Kaib (2002), S. 20. Vgl. Kapitel 3.3.1.

Techniken

147

ersten Schritt die Informationsverflechtungen zwischen den einzelnen Prozessschritten zu untersuchen. Dieser Schritt zielt auf eine erste Eingrenzung der Integrationsbereiche, die sich aufgrund interdependenter Prozessschritte ergeben. Im Anschluss daran sind die informationsverarbeitenden Systeme den Prozessschritten zuzuordnen. Die tatsächliche Identifikation der Integrationsbereiche erfolgt schließlich durch die Betrachtung der Abhängigkeiten zwischen der Informationsverarbeitung. Die Analyse dieses Vorgehens deckt jedoch Defizite im Hinblick auf die Identifikation der zwei Integrationsbereichstypen in Unternehmensnetzwerken auf.371 Hintergrund dieser Defizite ist die Konzentration der Integrationsmethoden auf die Ermittlung der Integrationsbereiche, die auf eine nachträgliche Integration bereits im Einsatz befindlicher Anwendungssysteme – im Sinne einer ex-post Integration – zielt. Für den Einsatz der Methode in Netzwerken ist sie entsprechend um die Identifikation von Integrationsbereichen zu erweitern, so dass sich im Sinne einer ex-ante Integration und damit für Prozesse ebenfalls Integrationsbereiche aufdecken lassen, die derzeit nicht maßgeblich von Anwendungssystemen unterstützt werden.372 Die Ermittlung der Integrationsbereiche, die durch eine ex-post Integration etwa mittels der Architekturen des Daten-Sharings und der Applikations-Kommunikation geschlossen werden, erfolgt im Wesentlichen in Anlehnung an das verbreitete Vorgehen im Rahmen des Integrationsmanagements.373 Dabei sind zunächst die vorhandenen Anwendungssysteme zu erfassen und im Hinblick auf die Informationsflüsse zu untersuchen, die zwischen diesen verlaufen. Darüber hinaus zielt die Methode auf die Identifikation von Integrationsbereichen, die im Sinne einer ex-ante Integration typischerweise mit dem Applikations-Sharing als dritte Architektur geschlossen werden. Kennzeichen dieser Integrationsbereiche ist die weitgehend fehlende Systemunterstützung vollständiger Prozessschritte. Durch die Ermittlung der Lücken, welche die Prozessschritte im Hinblick auf die Anwendungssystemunterstützung aufweisen, lassen sich entsprechende Integrationsbereiche identifizieren. Das dazu gewählte Vorgehen ist angelehnt an die im Informationsmanagement verbreiteten Ansätze zur Integrationsbereichsidentifikation. Dort entwickelten sich unter dem Stichwort „Strategic Information Systems Planning“ (SISP) insbesondere in den 1980er und 1990er Jahren Vorgehensweisen, die sich mit dem Zusammenspiel der Geschäftsstrategie bzw. -architektur und den sich dar-

371

372 373

Hintergrund dieser Defizite ist wohl das mehrheitlich aus Sicht von Einzelunternehmen geprägte Vorgehen, bei dem die Integration auf „grüner Wiese“ und damit für Prozesse, die bisher nicht durch Anwendungssysteme unterstützt wurden, als Ausnahme angesehen wird Kurbel/Rautenstrauch (1996), S. 169. Ähnlich Krumbiegel (1997), S. 56-59. Vgl. etwa Österle et al. (1991), S. 112-117.

148

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

aus ergebenden Anwendungssystemarchitekturen eines Unternehmens befassen.374 Im Kern kennzeichnen sich diese Ansätze durch die Ableitung idealtypischer Anwendungssystemarchitekturen mitsamt Schnittstellen und dies ausgehend von der Unternehmensstrategie, verbunden mit der sich daraus ergebenden Aufbau- und Ablauforganisation. Besondere Bedeutung für die Integration hat von diesen Ansätzen das Business Systems Planning von IBM, bei dem die Ermittlung der Anwendungssystemarchitektur in Form eines semiformalen Modells anhand der Geschäftsstrategie und -architektur erfolgt.375 Die Aufdeckung der Integrationsbereiche resultiert im Wesentlichen aus der Ermittlung sämtlicher, im Unternehmen benötigter Daten, die im Anschluss den Unternehmensprozessen gegenüberzustellen sind. Integrationsbereiche für potenziell zu entwickelnde Anwendungssysteme ergeben sich durch die Betrachtung von Prozesskomponenten, die auf ähnliche Datenmuster zugreifen (vgl. Abb. 4.4.2.1/1).

Daten

Prozesse

Management

Datenfluss Vertrieb

Produktion

mögliches Anwendungssystem

Abb. 4.4.2.1/1: Anwendungssystemarchitektur nach dem Business System Planning376

Aufgrund der hohen Komplexität und dem mit dem Ansatz verbundenen zeitlichen Aufwand – für die Definition der Daten eines Unternehmens werden vom Projektteam durchschnittlich fünf Tage benötigt – ist er für den Einsatz in Unternehmensnetzwerken anzupassen.377 Ermöglichen lässt sich dies, indem den Prozessen lediglich die 374 375

376 377

Vgl. Salmela/Spil (2002), S. 442-443; Ward et al. (1990), S. 10. Vgl. zur Übersicht Pant/Ravichandran (2001), S. 86-87. Zur Nutzung des Business Systems Planning für die Ermittlung von Integrationsbereichen vgl. Winter (2006), S. 8-9; Brenner (1994), S. 99102. Für vergleichbare Ansätze, die sich ebenfalls mit der Anwendungssystemarchitektur ausgehend von der Unternehmensarchitektur bzw. Strategie befassen vgl. die Übersicht in Krumbiegel (1997), S. 55-83; Lederer/Sethi (1988), S. 447-449. Vgl. im Folgenden IBM (1984), S. 5-49. In Anlehnung an Winter (2006), S. 9. Vgl. zur Komplexität des Ansatzes etwa Biethahn et al. (2000), S. 280-281; Batiste/Jung (1984), S.

Techniken

149

bestehenden Anwendungssysteme des Netzwerks gegenübergestellt werden. Mit dieser Gegenüberstellung lassen sich die Lücken aufdecken, die durch eine vom Applikations-Sharing geprägte Integrationsarchitektur zu schließen sind.378 4.4.2.2

Vorgehen

Das Ziel der Technik liegt in der Identifikation der Integrationsbereiche des Netzwerks. Wie in Abschnitt 4.4.2.1 beschrieben sind dabei zwei unterschiedliche Integrationsbereichstypen aufzudecken. Zur Erfassung der Integrationsbereiche, die typischerweise in Form einer ex-ante Integration geschlossen werden, bei der die Integration zeitlich vor der Implementierung der Anwendungssysteme stattfindet, gilt es Netzwerkprozesse aufzudecken, die bisher nicht bzw. kaum durch Anwendungssysteme unterstützt werden. Dazu sind die Anwendungssysteme des Netzwerks zu erfassen und den Netzwerkprozessen gegenüberzustellen. Schließlich sind die Integrationsbereiche aufzudecken, die aufgrund möglicher Abhängigkeiten zwischen den derzeit sich im Einsatz befindenden Anwendungssystemen des Netzwerks bestehen. Dazu sind die möglichen Abhängigkeiten aufzudecken und der bestehenden Anwendungssystemlandschaft des Netzwerks gegenüberzustellen, so dass sich nötige Schnittstellen aufdecken lassen. Diesen Zielen entsprechend sind im Hinblick auf die Technik zur Identifikation von Integrationsbereichen zunächst sämtliche Anwendungssysteme der Netzwerkprozesse aufzudecken. Ihre Gegenüberstellung mit den Prozessen lässt als erstes Zwischenergebnis Rückschlüsse auf bestehende Lücken in der Anwendungssystemlandschaft des Netzwerks zu. Die Aufdeckung der Kommunikationsbeziehungen innerhalb und zwischen den Prozessen sowie die Untersuchung, inwiefern diese von den vorhandenen Anwendungssystemen des Netzwerks unterstützt werden, führt schließlich zur Aufdeckung von Integrationsbereichen, die zwischen bereits bestehenden Anwendungssystemen bestehen. Sämtliche Schritte der Technik sowie Input- und Ergebnisdokumente zeigt Abb. 4.4.2.2/1.

378

215-216. Vgl. Krcmar (2003), S. 155.

150

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

nötige Input-Dokumente 1.

Erfassung der IstAnwendungssysteminfrastruktur

2.

Integrationsbereiche aufgrund fehlender Anwendungssysteme ermitteln

• für Integration relevante Netzwerkprozesse • Netzwerkprozess-Organisations-Diagramm

erhaltene Ergebnisdokumente

Vorgehen

3.

Kommunikationsbeziehungen erfassen

4.

Integrationsbereiche aufgrund interdependenter Anwendungssysteme ermitteln

• Anwendungssystemlandkarten • System Prozess-Matrix • Übersicht der Kommunikationsbeziehungen • Detailanalyse der Kommunikationsbeziehungen • verabschiedete Integrationsbereiche

Abb. 4.4.2.2/1: Vorgehensschritte und Ergebnisdokumente zur Integrationsbereichsidentifikation

Schritt 1: Erfassung der Ist-Anwendungssysteminfrastruktur Das Ziel des ersten Schritts liegt in der Erfassung sämtlicher für die Integration der Netzwerkprozesse relevanter Anwendungssysteme. Von der Menge aller Anwendungssysteme der Partnerunternehmen des Netzwerks sind entsprechend lediglich die für die Netzwerkarbeit relevanten Systeme abzugrenzen. Um dies zu gewährleisten erfolgt die Suche der Systeme aus Sicht der bereits ermittelten Netzwerkprozesse und Partner, die im Rahmen der Prozesse Aufgaben übernehmen. Ausgangspunkt des Vorgehens sind die für die Integration als relevant gekennzeichneten Netzwerkprozesse. Die Ermittlung der Anwendungssysteme kann in Form einer tabellarischen Erfassung sowie grafisch unterstützt erfolgen, etwa in Form einer netzwerkspezifischen Anwendungssystem-Landkarte. Die AnwendungssystemLandkarte zeigt allgemein sämtliche IT-Systeme in der Übersicht, die im Rahmen der Leistungserstellung eines Prozesses relevant sind (vgl. Abb. 4.4.2.2/2).379 Unabhängig von der grafischen oder tabellarischen Variante sind anhand des Netzwerk-Organsiations-Diagramms zunächst die Partner zu ermitteln, die an der Leistungserstellung eines Prozesses potenziell beteiligt sind. Daran anschließend sind für diese Partnerunternehmen die Anwendungssysteme zu ermitteln, welche im Rahmen der jeweiligen Prozesse eingesetzt werden. Zu unterscheiden ist dabei, inwiefern die bestehenden Anwendungssysteme Hauptfunktionen der Leistungserstellung eines Prozesses unterstützen oder lediglich für Nebenfunktionen Unterstützung leisten.380 379

380

Vgl. Steinbock (1994), S. 33-34; Österle (1995), S. 139-142.Für einen ausführlichen Ansatz vgl. Lankes et al. (2005), S. 1443-1461. Für eine Softwarelandkarte in tabellarischer Form vgl. etwa Uebernickel et al. (2006), S. 204-205. Ähnlich Treuling (1990), S. 50-51. Die Unterscheidung erleichtert im Anschluss die Ermittlung von Prozessen, denen weitgehend eine Unterstützung durch Anwendungssysteme fehlt.

Techniken

151

Netzwerkpartner n

AS n

Netzwerkpartner 1

AS 1

Prozess 1 AS 2

...

AS = Anwendungssystem = unterstützt Hauptfunktion

...

= unterstützt Nebenfunktion

Abb. 4.4.2.2/2: Anwendungssystem-Landkarte zur Systemerfassung381

Schritt 2: Integrationsbereiche aufgrund fehlender Anwendungssysteme ermitteln Die gesammelten und den Netzwerkpartnern zugeordneten Anwendungssysteme sind anschließend in einer konsolidierten Sicht den Prozessen gegenübergestellt. Dies erfolgt in Form einer Matrix, bei der die von den Netzwerkpartnern eingesetzten Anwendungssysteme den Prozessen gegenübergestellt sind. Innerhalb der Schnittstellen ist dabei zu verzeichnen, inwiefern ein Netzwerkpartner überhaupt am Prozess beteiligt ist und inwiefern die eingesetzten Systeme maßgeblich oder geringfügig zur Unterstützung der Informationsverarbeitung eines Prozesses eingesetzt werden.382 Auf einem hohen Aggregationsniveau erlaubt die Analyse der Lücken dieser Matrix entsprechend die Ermittlung der Prozesse, bei denen die Informationsverarbeitung – aufgrund der fehlenden Anwendungssystemunterstützung – weitgehend ohne Automatisierung erfolgt.383 Im Rahmen einer vereinfachten Darstellung sind nicht sämtliche Anwendungssysteme einzeln aufzuführen, sondern es ist lediglich in den Schnittstellen der Matrix zu vermerken, inwiefern ein Netzwerkpartner für den jeweiligen Prozess ein Anwendungssystem einsetzt (vgl. Abb. 4.4.2.2/3). Für Netz-

381

382 383

In Anlehnung an Steinbock (1994), S. 33-34, wobei in der ursprünglichen Version nach Steinbock nicht der Prozess, sondern ein Anwendungssystemtyp im Mittelpunkt steht. Die Ringe bilden in der ursprünglichen Variante den Reifegrad konkreter Anwendungssysteme, die zum jeweiligen Typ zählen. Innerhalb der Literatur findet sich jedoch ebenfalls eine Variante, bei der bereits der Prozess im Mittelpunkt der Landkarte steht, um den die unterstützenden Anwendungssysteme abgetragen werden (vgl. Österle (1995), S. 141). Vgl. Schumann et al. (1994), S. 46. Vgl. etwa Krcmar (2003), S. 154; Martin (1990), S.186-190.

152

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

werke mit vielen Anwendungssystemen lässt sich die Aufdeckung der Lücken auf diese Weise vereinfachen.384

Prozesse 1 Partner 1 AS

2

...

...

n

AS 1 AS 2

Partner 2 AS nicht beteiligte Netzwerkpartner

...

Netzwerkpartner setzt AS für Hauptfunktion ein

Partner n AS

Netzwerkpartner setzt AS für Nebenfunktion ein AS = Anwendungssystem

Prozesse mit geringer Anwendungssystemunterstützung

Abb. 4.4.2.2/3: Vereinfachte System-Prozess-Matrix385

Grundsätzlich kennzeichnen die Lücken in der Matrix solche Prozesse, bei denen bedeutende Potenziale durch den Einsatz eines integrierten Anwendungssystems für eine automatisierte Informationsverarbeitung vermutet werden. Anhand dieser Lücken ist schließlich vom Netzwerk zu entscheiden, inwiefern die Informationsverarbeitung eines Prozesses zukünftig zu integrieren und damit zu automatisieren ist. Diese Entscheidung über die Integrationsbereiche aufgrund der fehlenden Anwendungssystemunterstützung ist schließlich gemeinsam vom Netzwerk zu treffen und zu verabschieden.

Schritt 3: Kommunikationsbeziehungen erfassen Nach der Erfassung der Integrationsbereiche, die aufgrund einer fehlenden Anwendungssystemunterstützung bestehen, sind im Folgenden die Integrationsbereiche zwischen den existierenden Anwendungssystemen des Netzwerks aufzudecken. Dazu sind zunächst die möglichen Informationsflüsse zwischen den Prozesskomponenten zu erfassen. Dies erfolgt in Anlehnung an das klassische Vorgehen zur Identifika-

384

385

Setzt ein Netzwerkpartner für einen Prozess mehrere Systeme ein, lässt sich dies in der vereinfachten Darstellung in Textform in den Schnittstellen vermerken. Die Unterscheidung der maßgeblichen oder geringfügigen Prozessunterstützung richtet sich dann danach, inwiefern ein Netzwerkpartner überhaupt ein System für den Prozess einsetzt, welches diesen maßgeblich unterstützt. In Anlehnung an Neu (1991), S. 60; Schumann et al. (1994), S. 46.

Techniken

153

tion von Integrationsbereichen durch eine Input-Process-Output-Analyse.386 Mit Ausnahme der Prozesse, bei denen bereits im Rahmen der ersten beiden Schritte dieser Technik Integrationsbereiche identifiziert wurden, sind für sämtliche restlichen Prozesskomponenten des Netzwerks die für die Leistungserstellung benötigten Informationsobjekte zu ermitteln. Dabei ist zu unterscheiden, welche Informationsobjekte als Input für eine Prozesskomponente erforderlich sind und welche Informationsobjekte die jeweilige Prozesskomponente als Output generiert (vgl. Abb. 4.4.2.2/4). InformationsInput

Prozesskomponente

InformationsOutput

Produktion

Produktstatus

Herstellungsinformationen Bestellinformationen Produktionsplan

Abb. 4.4.2.2/4: Input-Process-Output-Analyse387

Anhand der Betrachtung der gemeinsam genutzten Informationsobjekte zwischen den Prozesskomponenten lassen sich die Kommunikationsbeziehungen des Netzwerks ermitteln.388 Kennzeichen einer Kommunikationsbeziehung ist das Zusammentreffen eines Informationsangebots von einem Informationserzeuger mit der Informationsnachfrage eines Informationsnutzers.389 Entsprechend erfolgt ihre Ermittlung durch die Analyse der Informationsoutputs, die für eine andere Prozesskomponente Informationsinputs darstellen.390 Die Übertragung der ermittelten Kommunikationsbeziehung in eine Matrix verdeutlicht die Informationsflüsse des Netzwerks. Die Gruppierung der Prozesskomponenten entsprechend den zugehörigen Prozessen ermöglicht die Unterscheidung der inter- und intraprozessualen Kommunikationsbeziehungen im Netzwerk. In den Schnittstellen der Matrix ist zu erfassen, inwiefern eine Prozesskomponente ein In-

386

387 388 389

390

Vgl. Österle et al. (1991), S. 114. Mantel et al. (2004), S. 32 schlagen zur Informationsflussermittlung die Erstellung eines Interaktionsschema (IAS) vor. Im Kern deckt dieses ähnlich die Verknüpfung von Prozesskomponenten auf (vgl. Ferstl/Sinz (2001), S. 183-184). In Anlehnung an IBM (1984), S. 37. Vgl. Stietz (1995), S. 168. Vgl. Treuling (1990), S. 46-47. Die Summe aller Kommunikationsbeziehungen ergibt entsprechend den Informationsfluss. Vgl. Koreimann (2000), S. 74-75; Batiste/Jung (1984), S. 221.

154

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

formationsobjekt einer weiteren Prozesskomponente nutzt bzw. bereitstellt (vgl. Abb. 4.4.2.2/5). Kommunikationsbeziehung i Bereich interprozessualer Kommunikationsbeziehungen

Prozess 1

...

Prozesskomponente n

...

...

...

...

Prozesskomponente 3

Prozesskomponente 2

Prozesskomponente 1

Bereich intraprozessualer Kommunikationsbeziehungen

Prozess n

Prozesskomponente x benötigt Inputs der Prozesskomponente x+n Prozesskomponente x+n benötigt Inputs der Prozesskomponente x Prozesskomponente x+n benötigt Inputs der Prozesskomponente x Prozesskomponente x benötigt Inputs der Prozesskomponente x+n

Abb. 4.4.2.2/5: Erfassung der Informationsflüsse im Netzwerk391

Schritt 4: Integrationsbereiche aufgrund interdependenter Anwendungssysteme ermitteln Anhand der Kommunikationsbeziehungen und der aufgedeckten interdependenten Nutzung von Informationsobjekten im Netzwerk sind schließlich die Integrationsbereiche zwischen den bestehenden Anwendungssystemen zu ermitteln. Dazu sind zunächst für sämtliche Kommunikationsbeziehungen die zugehörigen Anwendungssysteme innerhalb des Netzwerks zu erfassen. Ausgangspunkt ist die bereits im ersten Schritt erstellte Anwendungssystemübersicht. Anhand dieser ist zu untersuchen, inwiefern die für einen Prozess eingesetzten Anwendungssysteme der Netzwerkpartner die im Rahmen einer Kommunikationsbeziehung übertragenen Informationsobjekte verwenden. Zu unterscheiden sind dabei die Anwendungssysteme, die das entsprechende Informationsobjekt bereitstellen (Outputsysteme) von den Anwendungssystemen, die dieses nutzen (Inputsysteme). Schließlich sind die Input- und Outputsysteme jeder Kommunikationsbeziehung in Form einer Matrix gegenüberzustellen. In den Schnittstellen der Matrix ist verzeich-

391

In Anlehnung an Stietz (1995), S. 168.

Techniken

155

net, inwiefern die automatisierte bzw. teilautomatisierte Übertragung der Informationsobjekte aus den Outputsystemen in die Inputsysteme Verbesserungspotenziale durch die Optimierung des Informationsflusses – etwa durch die Eliminierung von Medienbrüchen – birgt.392 Setzt ein grundsätzlich an der Kommunikationsbeziehung beteiligter Netzwerkpartner kein Anwendungssystem ein, so ist dies ebenfalls zu kennzeichnen (vgl. Abb. 4.4.2.2/6).

Inputsysteme

Outputsysteme

Kommunikationsbeziehung i

NW 1

...

NW n

AS 1

...

AS n

NW 1

AS 5

A

A

A

NW 2

-

2

2

2

...

...

A

A

A

NW m

AS m

A

3

A

A

= Automatisierungspotenzial zwischen den AS

2 3

= fehlendes Anwendungssystem = bereits automatisierte Übertragung der Informationsobjekte

Abb. 4.4.2.2/6: Detailanalyse der Kommunikationsbeziehung

Anhand der Matrix erfolgt schließlich im Netzwerk die Entscheidung, inwiefern eine Kommunikationsbeziehung als Integrationsbereich für das weitere Vorgehen der Methode zu behandeln ist. Grundsätzlich liegen Integrationsbereiche vor, sofern mindestens ein Automatisierungspotenzial bei der Übertragung von Informationsobjekten ermittelt wurde.393 Im Rahmen des tatsächlichen Einsatzes der Methode ist allerdings zu erwarten, dass eine Kommunikationsbeziehung als Integrationsbereich für das Netzwerk behandelt wird, sofern die überwiegende Anzahl der einzelnen Informationsobjektübertragungen Automatisierungspotenziale beinhaltet. Bei lediglich einer geringen Anzahl aufgedeckter Automatisierungspotenziale in der Matrix ist hingegen

392

393

Vgl. Mantel et al. (2004), S. 32. Grundsätzlich können die Einschätzungen auch auf Partnerebene und damit von den einzelnen Netzwerkpartnern getrennt erfolgen. Die einzelnen Einschätzungen lassen sich dann zu einer Gesamteinschätzung auf Netzwerkebene konsolidieren. Ebenfalls können sich Integrationsbereiche bei fehlenden Anwendungssystemen ergeben, sofern das Netzwerk entscheidet, diese – etwa in Form einer Datenbank für das Daten-Sharing – gemeinschaftlich einzusetzen.

156

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

die Integration nicht auf Netzwerkebene, sondern auf bilateraler Ebene zwischen den jeweiligen Netzwerkpartnern zu erwarten. Sämtliche aufgedeckten Integrationsbereiche sind schließlich vom Netzwerk zu dokumentieren und zu verabschieden. Im Rahmen der Dokumentation (Integrationsbereichs-Definition) sind die entsprechenden Kommunikationsbeziehung und das Informationsobjekt sowie die vom Integrationsbereich betroffenen Input- und Outputsysteme zugeordnet zu den jeweiligen Netzwerkpartnern festzuhalten. Des Weiteren sind im Rahmen der Dokumentation die bereits im zweiten Schritt ermittelten Integrationsbereiche zu berücksichtigen. Anstelle der Kommunikationsbeziehung und dem Informationsobjekt sind dabei jedoch die betroffenen Prozesse aufzunehmen. 4.4.3 Evaluation der Integrationsbereiche Die Technik zur Evaluation zielt auf eine erste Bewertung und anschließende Priorisierung der identifizierten Integrationsbereiche. Dies ist nötig, da im Rahmen der zuvor durchgeführten Phase noch keine Unterscheidung im Hinblick auf die Bedeutung der identifizierten Integrationsbereiche vorgenommen wurde. Entsprechend wird im Rahmen dieser Technik zunächst ermittelt, welche Informationsflüsse im Rahmen der Netzwerkarbeit von hervorzuhebender Bedeutung sind. Dieser Einschätzung folgend sind die Integrationsbereiche gemäß ihrer Bewertung in eine Rangfolge zu bringen. Den Abschluss der Technik bildet entsprechend die Auswahl der im folgenden Methodenverlauf zu realisierenden Integrationsbereiche. 4.4.3.1

Ansatz

Die vorliegende Technik zielt auf eine Eingrenzung und damit Filterung der bisher aufgedeckten potenziellen Integrationsbereiche. Zur Entscheidung über die Auswahl oder Entwicklung von Anwendungssystemen werden in der Literatur typischerweise vier Aspekte aufgeführt, die besonders zu berücksichtigen sind.394 Zum einen soll die durchzuführende Beurteilung hervorheben, inwiefern ein potenzielles Anwendungssystem das Erreichen der strategischen Ziele des Unternehmens verbessert.395 Ferner gilt es bei der Entscheidung über potenzielle Systeme solche auszuwählen, die eine möglichst hohe Wirkung auf die fachbezogene Aufgabe haben. Darüber hinaus sollen lediglich Anwendungssysteme entwickelt werden, deren Wirtschaftlichkeit möglichst hoch und deren Umsetzungsrisiko möglichst gering ist.396 Im Rahmen der Realisierung von Integrationsbereichen gilt es ebenfalls, diese Aspekte zu berück-

394 395 396

Vgl. u. a. Mertens et al. (2005), S. 186. Vgl. etwa Cooke-Davies (2002), S. 188; Henderson/Venkatraman (1999), S. 472-474. Vgl. Müller et al. (2003), S. 58; Cash et al. (1992), S. 175-191.

Techniken

157

sichtigen. So ist die Integration insbesondere als sinnvoll zu erachten, wenn sie die übergeordneten Ziele unterstützt. Ebenfalls ist die Realisierung solcher Integrationsbereiche zu bevorzugen, bei denen der höchste Integrationsbedarf besteht und die durch eine besondere Wirtschaftlichkeit bei einem geringen Realisierungsrisiko gekennzeichnet sind.397 Für die Bedeutungsbestimmung der Anwendungssysteme sind mit Portfolioansätzen sowie der Technik der kritischen Erfolgsfaktoren insbesondere zwei grundsätzliche Vorgehensweisen verbreitet.398 Der folgende Abschnitt stellt diese Ansätze skizzenhaft vor, so dass im Anschluss ihre Eignung für die Evaluation von Integrationsbereichen in Unternehmensnetzwerken überprüft werden kann. Die Bedeutung von Anwendungssystemen ist zum einen mittels Portfolioansätze abzuleiten.399 Im Kern reduzieren diese Ansätze vieldimensionale Probleme typischerweise auf eine zweidimensionale Darstellung und versuchen dadurch, die Entscheidungsfindung zu erleichtern.400 Dazu sind zunächst die Portfoliodimensionen sowie die Bewertungskriterien für die Dimensionen und ihre jeweilige Gewichtung festzulegen. Im Anschluss daran ist für jedes zu bewertende Anwendungssystem die Ausprägung der einzelnen Kriterien zu bestimmen und im Portfolio zu positionieren.401 Zur Veranschaulichung und vereinfachten Interpretation lassen sich innerhalb des Portfolios zusätzlich einzelne Bereiche festhalten, denen grundsätzliche Handlungsmöglichkeiten zugeordnet werden können, wie etwa investieren oder desinvestieren.402 Zur Priorisierung von durchzuführenden Anwendungssystemprojekten ist eine Reihe von Ansätzen verbreitet. Im Kern werden damit potenzielle Projekte im Hinblick auf die Unterstützung der strategischen Ziele und ihren Nutzen für die Organisation evaluiert. Portfolios zur Evaluation von Integrationsbereichen hingegen finden sich nicht. Als zweiter Ansatz zur Bedeutungsbestimmung von Anwendungssystemen ist die Technik der Bestimmung von kritischen Erfolgsfaktoren verbreitet. Der ursprüngliche Ansatz zielt auf die Ermittlung des Informationsbedarfs des Managements für die Entwicklung von Managementinformationssystemen (MIS).403 Kritische Erfolgsfaktoren sind als einige zentrale Faktoren zu verstehen, die den Erfolg oder Misserfolg

397 398 399 400

401 402 403

Ähnlich Jung (1995), S. 544-549. Vgl. Krcmar (2003), S. 241; Gabriel/Beier (2003), S. 140. Vgl. u. a. Morris/Jamieson (2005), S. 7 und die dort zitierten Literaturangaben. Vgl. Ward (1988), S. 205. Siehe auch die besonders verbreiteten Ansätze von Porter/Millar (1985); McFarlan et al. (1983); Krcmar/Buresch (1994). Vgl. Schwarze (1998), S. 176-177. Vgl. Klotz/Strauch (1990); S. 49-50; Willcocks (2001), S. 276-277. Vgl. Rockart (1979), S. 81-93.

158

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

eines Unternehmens bestimmen.404 Angeknüpft wird dabei an die Ziele eines Unternehmens, aus denen die kritischen Erfolgsfaktoren abzuleiten sind. Im ursprünglichen Ansatz bildete ihre Definition die Grundlage der Informationen, die in einem MIS abzubilden sind. Die Erweiterung der Technik ermöglicht die Beschreibung des Verhältnisses zwischen dem Unternehmen und dessen Anwendungssystemen und ist damit nicht ausschließlich auf die Entwicklung von MIS beschränkt.405 Für die Bedeutungsbestimmung von Anwendungssystemen werden die aus den Zielen abgeleiteten Erfolgsfaktoren und Beurteilungsobjekte – wie etwa Integrationsbereiche – gegenübergestellt. Analysiert wird bei der Gegenüberstellung, inwiefern das Beurteilungsobjekt die jeweiligen Erfolgsfaktoren unterstützt. Unterscheiden lassen sich entsprechend Beurteilungsobjekte, welche zum Erreichen der Erfolgsfaktoren besser oder schlechter beitragen. Die vorgestellten Ansätze decken jeweils bestimmte Fragen zur Auswahl von zu realisierenden Integrationsbereichen ab. Im Rahmen der im Folgenden beschriebenen Ansätze werden diese jedoch nicht aneinander gereiht verwendet, sondern zu einer allein stehenden Technik verknüpft.406 Zunächst wird dafür die Bedeutung eines Integrationsbereichs analyisert. Um dabei die bereits ermittelten Netzwerkziele zu berücksichtigen, wird auf den Ansatz der kritischen Erfolgsfaktoren zurückgegriffen.407 Dabei wird der klassische Ansatz für einen Einsatz in Netzwerken insofern erweitert, als eine auf Partnerebene erfolgte Einschätzung der Erfolgsfaktorenunterstützung eines Integrationsbereichs zu einer Einschätzung auf Netzwerkebene konsolidiert wird. So gewährleistet der Ansatz, dass Integrationsbereiche bevorzugt ausgewählt werden, sofern sie im Einklang mit den Netzwerkzielen stehen. Zusätzlich ist zur Ermittlung der Bedeutung eines Integrationsbereichs der jeweilige Integrationsbedarf zu erfassen. Dies erfolgt durch die Einordnung der Integrationsbereiche in ein Portfolio. Dazu geht der Ansatz davon aus, dass der Integrationsbedarf von den zu verarbeitenden Datenvolumina und den Aktualitätsanforderungen des von der Integration betroffenen Informationsflusses abhängig ist.408 Ebenfalls lässt sich die auf Partnerebene vorgenommene Einschätzung des Integrationsbedarfs zu einer netzwerkübergreifenden Einschätzung zusammenfassen.

404

Vgl. Voß/Gutenschwager (2001), S. 148. Vgl. etwa Pfeffers et al. (2003), S. 56; Krcmar (2003), S. 247. 406 Vgl. Klotz/Strauch (1990), S. 54-55; Riedl (1991), S. 59-60. 407 Wie beschrieben ermöglicht dieser Ansatz die Beleuchtung der Frage, wie stark ein Integrationsbereich überhaupt die Ziele eines Netzwerks tangiert. 408 Ähnlich Schwinn (2003), S. 15-16; Monczka/Carter (1988), S. 4. Zur Verwendung der Portfolioanaylse in Netzwerken vgl. etwa Kontos (2004), S. 295-304. 405

Techniken

159

Neben der zu ermittelnden Bedeutung wird im Rahmen der Technik die Attraktivität der Realisierung der Integrationsbereiche untersucht. Dies erfolgt durch die Einordnung der Integrationsbereiche in ein Portfolio mit den Dimensionen Integrationsnutzen und -risiko. Für die Einordnung sind von den Netzwerkpartnern für beide Dimensionen zunächst geeignete Kriterien zu definieren und zu gewichten, anhand derer im Anschluss die einzelnen Integrationsbereiche einzuordnen sind.409 Die Zusammenführung der Einschätzung von Integrationsbedeutung und -attraktivität in einem übergeordneten Portfolio erlaubt schließlich die Ableitung von Normstrategien für jeden der bewerteten Integrationsbereiche. 4.4.3.2

Vorgehen

Das Vorgehen der Technik Evaluation von Integrationsbereichen umfasst drei Schritte. Zu Beginn steht dabei die Entwicklung eines Teilportfolios, das die Bedeutung eines Integrationsbereichs zeigt. Diese ergibt sich aus der zu ermittelnden jeweiligen Zielunterstützung eines Integrationsbereichs sowie dem jeweils zu ermittelnden Integrationsbedarf. Darauf folgend wird durch die Entwicklung eines zweiten Teilportfolios die jeweilige Integrationsattraktivität eines Integrationsbereichs ermittelt. Dies erfolgt durch die Bildung eines Portfolios mit den Dimensionen Integrationsrisiko und -nutzen. Durch die Zusammenführung der beiden Teilportfolios zu einem zusammenfassenden Portfolio ist schließlich die Auswahl der Integrationsbereiche vorzunehmen. Abb. 4.4.3.2/1 fasst die drei Schritte sowie die Input- und Output-Dokumente der Technik übersichtsartig zusammen.

Vorgehen

1.

Aufbau des Teilportfolios „Integrationsbedeutung“

2.

Aufbau des Teilportfolios „Integrationsattraktivität“

3.

Zusammenfassende Evaluation und Auswahl der weiterzuverfolgenden Integrationsbereiche

• Zielverabschiedung • Definition der Integrationsbereiche

erhaltene Ergebnisdokumente

• Kritische Erfolgsfaktoren • Gesamtportfolio der evaluierten Integrationsbereiche • Erweiterte Definition der Integrationsbereiche

Abb. 4.4.3.2/1: Vorgehensschritte und Ergebnisdokumente zur Evaluation der Integrationsbereiche

409

Vgl. Schwarze (1998), S. 174-175.

160

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Schritt 1: Aufbau des Teilportfolios „Integrationsbedeutung Zum Aufbau des Teilportfolios „Integrationsbedeutung“ ist zunächst die jeweilige Zielunterstützung der Integrationsbereiche zu ermitteln. Dies erfolgt in Anlehnung an den Ansatz der kritischen Erfolgsfaktoren. Verwendung findet dabei ein Punktesystem, das die Bedeutung eines Integrationsbereichs für die Netzwerkziele bewerten lässt. Die Ermittlung der Zielunterstützung der Integrationsbereiche ist in zwei Teilschritte unterteilt. Im ersten Teilschritt sind die kritischen Erfolgsfaktoren zu untersuchen und zu gewichten. Im Anschluss daran werden in einem zweiten Teilschritt die Integrationsbereiche den gewichteten Erfolgsfaktoren gegenübergestellt. Ausgangspunkt des ersten Teilschritts ist die Zieldefinition, die sich aus der Abgrenzung der übergeordneten Netzwerkziele ergeben hat.410 Dazu sind aus den Vorgehenszielen des Netzwerks die kritischen Erfolgsfaktoren abzuleiten, also jene bestimmten Faktoren, die einen bedeutenden Beitrag zum Erreichen des jeweiligen Ziels leisten. Vier Quellen der kritischen Erfolgsfaktoren sind zu unterscheiden. So beziehen sie sich auf die (1) gesamte Branche in der sich das Netzwerk betätigt, (2) Wettbewerbsposition sowie -strategie und die geographische Lage des Netzwerks, (3) politische, soziale und ökonomische Umwelt sowie (4) temporäre Gegebenheiten, die, wie etwa die Phase der Netzwerkbildung, nur für einen begrenzten Zeitraum relevant sind.411 Zur besseren Handhabung sind die identifizierten Erfolgsfaktoren auf die wesentlichen Faktoren zu konsolidieren.412 Erfolgen kann dies durch eine Interdependenzanalyse, mit der sich Erfolgsfaktoren mit besonders hohem Einfluss auf andere Erfolgsfaktoren von denen mit niedrigem Einfluss unterscheiden lassen. Dazu sind zunächst sämtliche Erfolgsfaktoren von den Netzwerkpartnern im Hinblick auf ihre Interdependenzen zu bewerten.413 Die Bildung des Mittelwerts aus den Einzeleinschätzungen ermöglicht im Anschluss eine netzwerkübergreifende Analyse der Interdependenzen, die in eine Matrix mit den Erfolgsfaktoren als Dimensionen einzutragen sind. Zur tatsächlichen Auswahl der Erfolgsfaktoren sind die Zeilen der Matrix als Aktivsummen aufzuaddieren und ihr Mittelwert zu berechnen. Ausgewählt werden im Folgenden solche Erfolgsfaktoren, deren Aktivsumme höher ist als der gebildete Mittelwert der Aktivsumme.

410 411 412 413

Vgl. Kapitel 4.4.1. Vgl. Rockart (1979), S. 86-87; Neu (1991), S. 153-154. Vgl. Heinrich (2002), S. 387. Die „0“ symbolisiert etwa keinen bzw. einen geringen Einfluss eines Erfolgsfaktors auf den anderen. Mit „1“ wird ein mittlerer und mit „2“ ein hoher Einfluss symbolisiert.

Techniken

161

Für die ausgewählten Erfolgsfaktoren ist im Anschluss die Gewichtung zu ermitteln. Dies ist zum einen die Einschätzung ihrer Priorität im Sinne der Wichtigkeit und Bedeutung zum Erreichen der Netzwerkziele sowie zum anderen die Einschätzung ihrer Leistung im Sinne ihres Beitrags zur Zielerreichung abzugeben.414 Diese Einschätzung erfolgt zunächst auf die Partnerebene durch die entscheidungsbefugten Vertreter der Netzwerkpartner für sämtliche Erfolgsfaktoren. Aus dieser individuellen Einschätzung auf Partnerebene ist im Anschluss die geschätzte durchschnittliche Priorisierung eines jeden Erfolgfaktors (E(Ki)) in Abhängigkeit der Leistung eines jeden Erfolgsfaktors auf Netzwerkebene zu berechnen (vgl. Abb. 4.4.3.2/2). n

E(Ki )

¦ ( P ( K ) ˜ L ( K )) j 1

j

i

j

i

n

¦ ( P ( K )) j 1

j

i

Abb. 4.4.3.2/2: Berechnung der geschätzten durchschnittlichen Priorisierung eines Erfolgsfaktors auf Netzwerkebene415

Die Ausdrücke Pj und Lj stehen für die Einschätzungen der Priorität (P) sowie der Leistung (L) für die Zielereichung eines Erfolgsfaktors auf Partnerebene. Sie werden von jedem Partnerunternehmen (i = 1...n) jeweils für einen Erfolgsfaktor eingeschätzt. Dies erfolgt mithilfe einer geeigneten Skala, die diese Einschätzung unterstützt (vgl. Abb. 4.4.3.2/3). Skala zur Einschätzung der Priorität Pj eines Erfolgfaktors (Ki)

Skala zur Einschätzung der Leistung Lj eines Erfolgfaktors (Ki)

irrelevant:

Pj(Ki) = 1

sehr schlecht:

Lj(Ki) = 1

eventuell nützlich :

Pj(Ki) = 3

unzureichend:

Lj(Ki) = 3

wichtig:

Pj(Ki) = 5

gut:

Lj(Ki) = 5

sehr entscheidend:

Pj(Ki) = 7

ausgezeichnet:

Lj(Ki) = 7

Abb. 4.4.3.2/3: Mögliche Skala zur Einschätzung der Priorität und Leistung eines Erfolgfaktors416

Nach der Ermittlung der absoluten Bedeutung eines Erfolgfaktors ist abschließend deren jeweilige relative Bedeutung (G(Ki)) zu ermitteln. Dazu wird jeweils die eingeschätzte durchschnittliche Priorisierung eines Erfolgsfaktors durch die Summe aller durchschnittlichen Priorisierungen der Erfolgsfaktoren dividiert (vgl. Abb. 4.4.3.1/4).

414 415 416

Vgl. Gabriel/Beier (2003), S. 100. Vgl. Heinrich (2002), S. 386. In Anlehnung an Heinrich (2002), S. 386.

162

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

G(Ki )

n

E(Ki )

¦ ( E ( K )) i 1

i

Abb. 4.4.3.2/4: Ermittlung der relativen Bedeutung eines Erfolgsfaktors auf Netzwerkebene

Im Rahmen des zweiten Teilschritts werden die ermittelten und gewichteten Erfolgsfaktoren den Integrationsbereichen in Form einer Bewertungsmatrix zur Beurteilung der Attraktivität der Integrationsbereiche gegenübergestellt.417 Dazu ist zunächst die Bewertung auf Partnerebene dazuzuführen, aus der im Anschluss die Bewertung auf Netzwerkebene ermittelt wird. Die Bewertung auf Partnerebene erfolgt in einer Matrix, bei der in den Zeilen die kritischen Erfolgsfaktoren abgetragen sind und in den Spalten sämtliche Integrationsbereiche. An den Schnittpunkten der Zeilen und Spalten ist von den Partnern anhand einer Punkteskala zu bewerten, inwiefern ein Integrationsbereich aus ihrer individuellen Sicht einen der kritischen Erfolgsfaktoren unterstützt.418 Aus den jeweiligen individuellen Bewertungen ist im Anschluss (1) der Mittelwert zu bilden und (2) in die Bewertungsmatrix zur Beurteilung der Attraktivität der Integrationsbereich zu übertragen. In dieser Matrix sind ebenfalls die kritischen Erfolgsfaktoren (Spalten) den Integrationsbereichen (Zeilen) gegenübergestellt. Zusätzlich ist in der Matrix eine Spalte enthalten, in der die relativen Bedeutungen der jeweiligen Erfolgsfaktoren (Gewichtung) aus dem ersten Teilschritt abgetragen sind. Zur Beurteilung eines Integrationsbereichs werden (3) sämtliche Mittelwerte aus den Bewertungen der Netzwerkpartner einer Spalte jeweils mit der Gewichtung multipliziert und (4) abschließend aufsummiert, so dass die Gesamtbewertung eines Integrationsbereichs auf Netzwerkebene erhalten wird (vgl. Abb. 4.4.3.2/5).

417 418

Vgl. im Folgenden Biethahn et al. (2000), S. 289-299. Die Vergabe einer „0“ kennzeichnet etwa, dass ein Integrationsbereich keinen Beitrag für einen Erfolgsfaktor leistet. Eine „1“ hingegen steht für einen mittleren und eine „2“ für einen hohen Beitrag.

Techniken

163

Beurteilung Partner 1

Beurteilung Partner 2 Integrationsbereiche

Integrationsbereiche

KEFs

KEFs

KEFs

Integrationsbereiche

Beurteilung Partner n

1 Mittelwert 2

KEF = Kritische Erfolgsfaktoren

Gewichtung

KEFs

Bewertungsmatrix

Integrationsbereiche 3 3 3 4 Gesamt n

= Teilschritt

Abb. 4.4.3.2/5: Bewertung der Zielunterstützung der Integrationsbereiche

Zur vollständigen Ermittlung des Teilportfolios „Integrationsbedeutung“ ist schließlich der Integrationsbedarf eines jeweiligen Integrationsbereichs zu ermitteln. Der Integrationsbedarf gibt darüber Auskunft, inwiefern ein Integrationsbereich einen wesentlichen Beitrag zur Optimierung der Informationsflüsse des Netzwerks leistet. Ausgangspunkt der Ermittlung ist die Betrachtung des Informationsbedarfs der von einem Integrationsbereich betroffenen Anwendungssysteme. Die Ermittlung des Integrationsbedarfs erfolgt somit auf Ebene der logischen Informationsabhängigkeiten zwischen Anwendungssystemen und entsprechend ist seine Ermittlung unabhängig von der später gewählten Architektur eines Integrationsbereichs.419 Die Ermittlung des Integrationsbedarfs orientiert sich im Kern an zwei Aspekten. Diese befassen sich mit der Informationsmenge, die durch einen Integrationsbereich bewältigt wird sowie mit der Nutzungshäufigkeit eines Integrationsbereichs.420 Zur Beurteilung des Integrationsbedarfs werden die zu evaluierenden Integrationsbereiche in eine Matrix eingeordnet. Diese umfasst die Dimensionen (1) Aktualitätsanfor-

419

420

Keine Bedeutung spielt somit, in welcher Form der Informationsbedarf im Detail besteht, etwa im Hinblick auf die Daten oder die Funktionen der Anwendungssysteme, sondern welche Relevanz die Informationsflüsse im Rahmen der Gesamtarchitektur besitzen (vgl. Schwinn (2003), S. 11). Die Aspekte ergeben sich aus typischen Einsatzfeldern der Integration (vgl. etwa Emmelhainz (1990), S. 19; Hilbers (1992), S. 163; Monczka/Carter (1988), S. 4).

164

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

derungen des betroffenen Informationsflusses sowie (2) Komplexität der Informationsverarbeitung, die jeweils gering und hoch ausgeprägt sein können.421 Die Ermittlung der jeweiligen Ausprägungen wird durch einen Fragenkatalog unterstützt. Im Hinblick auf die Dimension Komplexität der Informationsverarbeitung ermittelt der Fragenkatalog, wie (1) das Volumen der zu verarbeitenden Daten durch einen Integrationsbereich sowie (2) die Anzahl der zur Datenverarbeitung nötigen Transaktionen ausgestaltet ist.422 Zu ermitteln ist, inwiefern diese Fragen für einen Integrationsbereich gering oder hoch ausgeprägt sind, woraus sich schließlich eine zusammenfassende Einschätzung der Komplexität für jeden Integrationsbereich ableiten lässt. Schließlich ist für die Aktualitätsanforderung zu erfassen, ob der Informationsfluss zeitverzögert und damit mit geringer Aktualitätsanforderung erfolgt, oder etwa mit hoher, z. B. bei Near- bzw. Realtime-Informationsflüssen.423 Die von den einzelnen Partnerunternehmen abgegebene Einschätzung des Integrationsbedarfs ist durch die Bildung eines Mittelwerts auf Netzwerkebene zu konsolidieren. Die ermittelte Einschätzung beider Dimensionen wird im Anschluss in die Matrix zur Beurteilung des Integrationsbedarfs übertragen (vgl. 4.4.3.2/6).

hoher Integrationsbedarf

hoch

Komplexität der Informationsverarbeitung

mittlerer Integrationsbedarf geringer

gering Integrationsbedarf

gering

hoch

Aktualitätsanforderungen des Informationsflusses

Abb. 4.4.3.2/6: Matrix zur Beurteilung des Integrationsbedarfs

Aus der Matrix ergeben sich drei Normstrategien für die eingeordneten Integrationsbereiche. Unterschieden werden Integrationsbereiche, bei denen aufgrund der beschränkten Komplexität der Informationsverarbeitung durch den Integrationsbereich sowie keine hervorzuhebenden Anforderungen an die Aktualität des betroffenen Informationsflusses lediglich ein geringer Integrationsbedarf besteht. Ein mittlerer Integrationsbedarf ist ferner bei Integrationsbereichen gegeben, bei denen eine Di-

421 422 423

Vgl. Böhm et al. (1996), S. 336. Vgl. Fischer (1999), S. 187. Vgl. Schwinn (2003), S. 16.

Techniken

165

mension der Matrix im geringen und die andere Dimension im mittleren Bereich liegt. Schließlich besteht entsprechend ein hoher Integrationsbedarf, wenn mindestens eine der Dimensionen hoch ausgeprägt ist. Das Teilportfolio „Integrationsbedeutung“ ist schließlich anhand der ermittelten Zielunterstützung der Integrationsbereiche sowie dem ermittelten Integrationsbedarf aufzubauen (vgl. Abb. 4.4.3.2/7). Dafür ist zunächst die relative Zielunterstützung zu ermitteln. Dies erfolgt durch die Division der jeweiligen Zielunterstützung eines Integrationsbereichs durch die Summe aller Zielunterstützungen der Bewertungsmatrix.

Zielunterstützung des Integrationsbereichs

Zur Einordnung des Integrationsbedarfs werden die Integrationsbereiche anhand der Felder „gering“, „mittel“ oder „hoch“ aus der Matrix zur Beurteilung des Integrationsbedarfs in das Teilportfolio übertragen.

hohe Integrationsbedeutung

IB1

h IB2

mittlere Integrationsbedeutung IB3

geringe Integrationsbedeutung

g

g

h Integrationsbedarf

IBi = Integrationsbereich

Abb. 4.4.3.2/7: Teilportfolio „Integrationsbedeutung“424

Schritt 2: Aufbau des Teilportfolios „Integrationsattraktivität“ Im zweiten Schritt wird die Attraktivität der potenziellen Integrationslösungen ermittelt. Diese setzt sich zum einem aus dem durch die Realisierung einer integrierten Lösung entstehenden (Projekt-)Risiken und zum anderen aus dem potenziellen Nutzen der integrierten Lösung zusammen.425 Der beschriebenen Zusammensetzung der Integrationsattraktivität folgend, besteht ihre Ermittlung aus drei Teilschritten. Im ersten Teilschritt erfolgt die Bewertung der Projektrisiken, die vom Netzwerk für die jeweilige Realisierung der ermittelten Integrationsbereiche erwartet werden. Dazu hat sich das Netzwerk zunächst auf eine Auswahl möglicher Risiken zu einigen und

424 425

In Anlehnung an Hage/Metken (1990), S. 57. Vgl. Armour (2005), S. 20.

166

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

diese zu gewichten.426 Die auszuwählenden Risiken für die Bewertung lassen sich in vier Klassen gliedern. Diese umfassen (1) den Umfang eines Integrationsprojekts, die (2) Erfahrung im Netzwerk mit Integrationstechnologien, (3) zu erwartender Projektstruktur sowie (4) gewählter Integrationslösung.427 Abb. 4.4.3.2/8 zeigt überblicksartig typische Aspekte zur Beurteilung der Risiken der Realisierung integrierter Lösungen, die bei der Auswahl der Beurteilungskriterien zu berücksichtigen sind. Projektumfang

Technologieerfahrung

• Erfahrung mit den betroffenen • Zu erwartende Integrationskosten Anwendungssystemen • Zu erwartende Projektdauer • Erfahrung mit • Anzahl der betroffenen Systeme Integrationsprojekten und Schnittstellen • Mögliche Involvierung externer • Anzahl der beteiligten Mitarbeiter Mitarbeiter • Anzahl betroffener Netzwerkpartner

Projektstruktur • Strukturierungsmöglichkeit des Integrationsprojekts • Relative Größe des Integrationsprojekts

Integrationslösung • Ausreichende Schließung des Integrationsbereichs • Akzeptanz durch die Mitarbeiter der Netzwerkpartner • Ausmaß Arbeitsablaufsänderung • Erweiterbarkeit der Lösung

Abb. 4.4.3.2/8: Aspekte zur Ermittlung der Integrationsrisiken428

Im Anschluss daran sind die Integrationsbereiche im Hinblick auf die ausgewählten und gewichteten Aspekte zur Ermittlung der Integrationsrisiken durch die Partner des Netzwerks einzuschätzen. Das Vorgehen dazu erfolgt in Anlehnung an die skizzierte Bewertung der Integrationsbereiche im Hinblick auf die kritischen Erfolgsfaktoren.429 Für die Ermittlung der Risiken sind die dafür ausgewählten Aspekte den Integrationsbreichen in Form einer Matrix gegenüberzustellen und jeweils von den Netzwerkpartnern zu bewerten.430 In den Zeilen dieser Matrix sind dazu die ausgewählten Aspekte zur Beurteilung der Risiken abgetragen und den Spalten gegenübergestellt, welche die Integrationsbereiche enthalten. Zur Ermittlung der Risikoeinschätzung auf 426

427 428

429 430

Vgl. Weber (2004), S. 451; Jacob et al. (1994), S. 120. Die Gewichtung erfolgt analog der bereits beschriebenen Gewichtung der kritischen Erfolgsfaktoren im ersten Schritt des vorliegenden Kapitels. Vgl. Cash et al. (1992), S. 177-178. Ähnlich Enz (2006), S. 222. Zusammengestellt aus Krcmar/Buresch (1994), S. 296; Österle et al. (1991), S. 225; Mertens et al. (1989), S. 131-132. Vgl. den ersten Schritt des vorliegenden Kapitels. Dies kann durch die Zuhilfenahme einer Rangskala erfolgen, bei der etwa die Vergabe einer „0“ für geringe Risiken, die der entsprechende Aspekt mit sich bringt, steht. Die „1“ hingegen weist auf mittlere und die Vergabe einer „2“ auf hohe Risiken hin. Ebenfalls möglich sind weiter differenzierte Skalen, wie sie zur Beurteilung der kritischen Erfolgsfaktoren vorgestellt wurden. Vgl. auch Daenzer/Huber (1999), S. 215-216.

Techniken

167

Netzwerkebene ist für jedes Feld der Matrix der Mittelwert aus den einzelnen Einschätzungen der Partner zu bilden und in eine Ergebnismatrix zu übertragen (vgl. Abb. 4.4.3.2/9). In dieser sind neben den Aspekten zur Beurteilung der Risiken und den Integrationsbereichen zusätzlich die festgelegten Gewichtungen der Aspekte zur Beurteilung der Risiken enthalten. Die Risikoeinschätzung eines Integrationsbereichs erfolgt schließlich durch die Aufsummierung der gewichteten Werte einer Spalte.

Gewichtung

Aspekte zur Risikoeinschätzung

Risikoeinschätzung

Integrationsbereiche

Gesamt

Abb. 4.4.3.2/9: Ergebnismatrix zur Risikoeinschätzung der Integrationsbereiche auf Netzwerkebene

Im zweiten Teilschritt erfolgt im analogen Vorgehen die Beurteilung des potenziellen Nutzens der integrierten Lösung.431 Der Nutzen eines Integrationsbereichs ergibt sich aus der Abwägung des zu erwartenden Ertrags über den Lebenszyklus der Integrationslösung und dem Aufwand der Realisierung.432 Zur Nutzenabschätzung sind zunächst Beurteilungskriterien des Nutzens zu ermitteln und zu gewichten. Daraufhin kann die Einschätzung des Nutzens eines Integrationsbereichs auf Partnerebene erfolgen, die im Anschluss für eine Beurteilung auf Netzwerkebene zu konsolidieren ist. Nutzeffekte einer integrierten Lösung ergeben sich in Form von Kostenreduzierungen, Zeiteinsparungen, Qualitätsverbesserungen und strategischen Aspekten.433 Abb. 4.4.3.2/10 zeigt in der Übersicht typische Aspekte zur Nutzenbeurteilung integrierter Lösungen, auf die zur Auswahl der Beurteilungskriterien zurückgegriffen werden kann.

431 432 433

Vgl. zum Vorgehen Riedl (1991), S. 147-154; Buss (1983), S. 121-125. Vgl. Krcmar/Buresch (1994), S. 296-297. Vgl. Kaib (2002), S. 27-34.

168

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Kosten

Zeit

• Vermeidung von Doppelarbeiten • Reduktion der Kosten für die Handhabung von Papierdokumenten • Reduktion der Übertragungskosten • Verminderung von Lagerkosten durch Prozessbeschleunigung

Qualität

• Beschleunigung der netzwerkübergreifenden Abläufe • Durchgängige Datenverfügbarkeit

Strategie

• Verminderung von Erfassungsfehlern bei der Dateneingabe • Umfassendere, verbesserte und aktuellere Datenbasis

• Aufbau von Markteintrittsbarrieren • Erhöhte Reaktionsfähigkeit am Markt • Angebot neuer Leistungen • Erhöhter Kundennutzen

Abb. 4.4.3.2/10: Aspekte zur Beurteilung des Nutzens einer integrierten Lösung434

Im dritten Teilschritt zur Ermittlung der Integrationsattraktivität ist für jeden Integrationsbereich die relative Risiko- und Nutzeneinschätzung zu ermitteln. Dies erfolgt anhand der Division der jeweiligen Risiko- bzw. Nutzeneinschätzung durch die Summe aller Risiko- bzw. Nutzeneinschätzungen der Integrationsbereiche. Die relativen Risiko- und Nutzeneinschätzungen sind schließlich in das Teilportfolio „Integrationsattraktivität“ zu übertragen (vgl. Abb. 4.4.3.2/11).435

hohe Integrationsattraktivität

Integrationsrisiko

g IB1

mittlere Integrationsattraktivität

IB3

h

geringe Integrationsattraktivität

IB2

g

h Integrationsnutzen

IBi = Integrationsbereich

Abb. 4.4.3.2/11: Teilportfolio „Integrationsattraktivität“

434 435

Vgl. u. a. Scheckenbach (1997), S. 25-26. In Anlehnung an Jeffery/Leliveld (2004), S. 44.

Techniken

169

Schritt 3: Zusammenfassende Evaluation und Auswahl der Integrationsbereiche Im dritten Schritt ist aus den Teilportfolios ein Kombinations-Portfolio zu erstellen. Dieses besteht aus den Dimensionen „Integrationsbedeutung“ und „Integrationsattraktivität“, die gering, mittel und hoch ausgeprägt sein können. Entsprechend der Einordnung der Integrationsbereiche in die zuvor erstellten Teilportfolios erfolgt deren Übertragung in das zusammenfassende Portfolio. Dazu ist aus den beiden Dimensionen der Teilportfolios jeweils ein Dimensionswert für das Kombinationsportfolios zu ermitteln und in das Kombinationsportfolio zu übertragen (vgl. Abb. 4.4.3.2/12).436

weiter zu verfolgende Integrationsbereiche

Integrationsattraktivität

h IB1 m

selektiv weiter zu verfolgende Integrationsbereiche

IB3 IB2

nicht weiter zu verfolgende Integrationsbereiche

g

g

m Integrationsbedeutung

h IBi = Integrationsbereich

Abb. 4.4.3.2/12: Kombinations-Portfolio der Integrationsbereichsevaluation

Sämtliche Integrationsbereiche sind im Anschluss durch die Vertreter der Netzwerkpartner im Hinblick auf die Plausibilität der Einordnung in das Portfolio zu untersuchen, um möglicherweise entstandene Inkonsistenzen im Rahmen der Evaluation der Integrationsbereiche aufzudecken. Ist die finale Einordnung der Integrationsbereiche in das Portfolio erfolgt, so sind anschließend die Integrationsbereiche auszuwählen, die vom Netzwerk weiter verfolgt werden. Dies erfolgt unter Zuhilfenahme der dem Portfolio zugeordneten Handlungsempfehlungen. Diese ergeben sich aus dem Grundgedanken der Förderung von attraktiven und starken Positionen sowie einer Vernachlässigung von unattraktiven und schwachen Positionen.437 Entsprechend empfiehlt sich die Weiterverfolgung von Integrationsbereichen, bei denen beide Dimensionen hoch ausgeprägt sind. Sind die Dimensionen hingegen niedrig ausgeprägt, so ist von einer Weiterverfolgung des jeweiligen Integrationsbereichs abzusehen. Keine einheitliche Empfehlung ergibt sich aus Integrationsbereichen im mittleren Bereich des Kombinations-Portfolios. Für Integrationsbereiche dieses Bereichs ist vom Netzwerk eine nochmalige vertiefende 436 437

Vgl. Riedl (1991), S. 153. Vgl. Pfeiffer/Dögl (1999), S. 454-457.

170

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Untersuchung vorzunehmen, um darauf aufbauend eine klare Entscheidung über die Weiterverfolgung bzw. deren Unterlassung zu treffen.438 Anhand des Kombinations-Portfolios sind die weiter zu verfolgenden Integrationsbereiche schließlich vom Netzwerk gemäß ihrer Priorität in eine Reihenfolge zu bringen und zur Steigerung der Bindungswirkung durch die Netzwerkpartner formal zu verabschieden. Dazu ist die erstellte Definition der Integrationsbereiche der vorherigen Techniken um die Aspekte zu erweitern, die zur Auswahl bzw. Ablehnung der Integrationsbereiche geführt haben. 4.4.4 Integrationsspezifikation Die folgende Technik zielt auf die Ermittlung des Soll-Konzepts eines jeweils untersuchten Integrationsbereichs und der damit verbundenen Identifizierung der potenziellen Realisierungsform ab. Mit dem Resultat der Technik in Form einer detaillierten Spezifikation definiert sie die technischen Eckpunkte der Integrationslösung. 4.4.4.1

Ansatz

Zur Spezifikation des Integrationsbereichs und der damit verbundenen Zuordnung einer Integrations-Architektur sind zunächst die gewünschten Anforderungen in Form der benötigten Funktionalitäten der Integrationslösung zu ermitteln. „Anforderung“ (Requirement) ist eine Bezeichnung aus dem Systems Engineering und als Aussage über eine zu erfüllende Systemspezifikation zu verstehen, welche die Grundlage der tatsächlichen Systementwicklung bildet. Entsprechend werden unter dem Anforderungsbegriff aus der Perspektive der Anwendungssystementwicklung die qualitativen und quantitativen Produkteigenschaften verstanden.439 Sie beschreiben die Erwartungen an das System in Form von Bedingungen, Zielen, Nutzen usw., die zukünftige Benutzer, Kunden oder Auftraggeber an das Produkt richten und dienen als Basis für die Abschätzung, Planung, Durchführung und Verfolgung der Projekttätigkeiten.440 Die Ermittlung und Berücksichtigung der bestehenden Anforderungen stellt somit eine zielgerichtete Anwendungssystementwicklung sicher.441 Ergebnis der Technik ist entsprechend die fachkonzeptionelle Spezifikation der Integrationslösung.442 Als Integrationslösung wird im Folgenden der zu etablierende Mechanismus verstanden, mit dessen Hilfe der unterbrochene Informationsfluss eines Integrationsbereichs automatisiert werden soll. 438 439 440 441 442

Vgl. Syring (1993), S. 192. Vgl. Balzert (2000), S. 98. Vgl. Ebert (2005), S. 9. Vgl. Partsch (1991), S. 14-15. Vgl. Holten (2003), S. 42.

Techniken

171

Der Bedarf einer detaillierten Ermittlung der Anforderungen entsteht vor allem durch die verhältnismäßig höheren Kosten für die Verbesserung eines existierenden Systems aufgrund einer mangelhaften Anforderungsanalyse im Vergleich zur vollständigen Ermittlung der Anforderungen vor der Systementwicklung. So übersteigen die Kosten einer nachträglichen Implementierung von Anforderungen in ein bestehendes System die Kosten für die Implementierung der gleichen Anforderungen im Rahmen des eigentlichen Entwicklungsprozesses um den Faktor 20 bis 200.443 Klassischerweise wird innerhalb des Software Engineerings zwischen zwei Anforderungstypen unterschieden.444 Funktionale Anforderungen als erster Typ enthalten Aussagen über die angebotenen Dienste bzw. Reaktionen auf Nutzereingaben und das Verhalten in bestimmten Situationen eines Anwendungssystems. Von funktionalen sind nicht-funktionale Anforderungen als zweiter Typ abzugrenzen. Nichtfunktionale Anforderungen sind Restriktionen der vom System angebotenen Dienste und Funktionen, etwa im Hinblick auf Plattformvoraussetzung, Ausfall- oder Zugriffszeiten.445 Vergleichbar mit der klassischen Anwendungssystementwicklung sind ebenfalls im Rahmen von Integrationsprojekten die mit einem Integrationsbereich verbundenen Anforderungen zu erfassen. Dabei sind funktionalen von nicht-funktionalen Anforderungen an eine Integrationslösung zu unterscheiden.446 Erstere umfassen Aktionen und Dienste, die eine integrierte Lösung unterstützt. In Anlehnung an die funktionalen Anforderungen der klassischen Anwendungssystementwicklung werden sie etwa in Form des Eingabe-/Ausgabeverhaltens der Lösung beschrieben. Für die Integration ist dabei von Bedeutung, welche Daten bzw. Funktionen mittels welcher Bearbeitungsschritte und Folgeaktivitäten unter Nutzung von technischen Hilfsmitteln oder weiteren Informationsquellen verwendet werden.447 Des Weiteren sind für Integrationslösungen nicht-funktionale Anforderungen zu berücksichtigen. Ihre Klassifizierung gelingt anhand der Systemmerkmale Verhalten und Struktur eines Anwendungssystems sowie anhand einer zeitpunkt- bzw. zeitraumbezogenen Betrachtung (vgl. Abb. 4.4.4.1/1).448

443 444 445 446 447 448

Vgl. Eberlein/Leite (2002). Vgl. etwa Sommerville (2001), S. 109-114. Vgl. Ebert (2005), S. 10-14. Vgl. etwa Eckert et al. (2003) S. 9; Suchan/Schneider (2006), S. 381. Vgl. Petri (1990), S. 156. Vgl. bei Ferstl (1992), S. 11-13. Siehe auch zu den nicht-funktionalen Anforderungen Eckert et al. (2003), S. 100-102.

172

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Verhalten

Struktur

zeitpunktbezogen

Korrektheit

Integration

zeitraumbezogen

Echtzeitverhalten

Flexibilität

Abb. 4.4.4.1/1: Systematisierung nicht-funktionaler Anforderungen nach Sinz449

Nach dieser Systematisierung nicht-funktionaler Anforderungen bezieht sich die Flexibilität einer Integrationslösung auf ihre Skalierbarkeit, Anpassbarkeit und Generizität.450 Unter die Skalierbarkeit werden dabei Anforderungen an die zukünftig bereitzustellende Erweitung der Integrationslösung gefasst. Die Ermittlung der Anpassbarkeit zielt auf die Erfassung des zukünftig bestehenden potenziellen Änderungsbedarfs der Integrationslösung sowohl aus fachlicher als auch technischer Perspektive. Anhand der Generizität wird schließlich erfasst, inwiefern die Integrationslösung gleichermaßen unterschiedliche Standards, etwa in Form von Datenformaten, oder Schnittstellen unterstützt. Unter dem Aspekt des Echtzeitverhaltens der Integrationslösung werden nichtfunktionale Anforderungen an die Dauer der Verarbeitungsvorgänge bzw. den Grad der Synchronisation zwischen den Vorgängen innerhalb der Integrationslösung und denen der abgebildeten Realität bestimmt.451 Festzustellen ist dabei der benötigte Grad an Verfügbarkeit etwa von gemeinsam genutzten Daten oder Funktionen, die benötigte Verarbeitungskapazität sowie die Aktualität der gemeinsam genutzten Daten. Anhand der nicht-funktionalen Anforderungen der Kategorie Integration wird schließlich der Integrationsgrad der Lösung bestimmt.452 Zu ermitteln ist dafür, inwiefern Daten oder Funktionen redundant zu halten sind, etwa als Rückfallstufe für Störfälle, sowie die Art und Anzahl der Kommunikationskanäle zur Verknüpfung der von der Integration betroffenen Komponenten. Im Rahmen der Kategorie Integration ebenfalls zu ermitteln sind möglicherweise benötigte Mechanismen, um zum einen die

449 450 451 452

Vgl. Ferstl (1992), S. 11. Vgl. Eckert et al. (2003), S. 100-101. Vgl. Mantel et al. (2004), S. 34. Vgl. Mantel et al. (2000), S. 3-6.

Techniken

173

Konsistenz etwa von zu verarbeitenden Daten zu gewährleisten, sowie zum anderen zur zielgerichteten Steuerung der Durchführung eines vom Anwendungssystem unterstützten Prozesses.453 Schließlich ist im Hinblick auf die Integrationskategorie zu erfassen, inwiefern eine Aufgabenträgerunabhängigkeit – etwa durch die Orientierung an übergeordneten Standards – angestrebt wird, um die Unabhängigkeit vom aktuellen Technologiestand zu erreichen. Innerhalb der Ansätze zum Integrationsmanagement wird das Vorgehen zur systematischen Ermittlung der Anforderungen einer Integrationsarchitektur kaum thematisiert. Der Fokus der Beschreibungen liegt typischerweise auf dem Ergebnis der Anforderungsermittlung, meist in Form eines strukturierten Dokuments bzw. Kataloges, in dem die Anforderungen zusammengefasst sind.454 Konkrete Hinweise zum Vorgehen der Anforderungsermittlung finden sich lediglich im Beitrag von Holten.455 Darin wird auf das „Requirements Engineering“ als Disziplin zur Anforderungsermittlung verwiesen. Entsprechend wird im Folgenden untersucht, inwiefern sich das Requirements Engineering für die Anforderungsermittlung von Integrationslösungen eignet und welche Anpassungen für einen Einsatz in Netzwerken vorzunehmen sind. Unter dem Schlagwort „Requirements Engineering“ findet sich eine Reihe von Ansätzen, welche die Ermittlung von Anforderungen zu entwickelnder Anwendungssysteme unterstützen. Einzuordnen ist das Requirements Engineering in die Konzeptionsphase eines Entwicklungsprozesses von Anwendungssystemen. Ergebnis des Requirements Engineering ist das ermittelte Verhalten eines zu entwickelnden Systems in Form einer fachkonzeptionellen Spezifikation, wie etwa ein Pflichtenheft, das den Ausgangspunkt für die tatsächliche Systementwicklung in den folgenden Entwicklungsphasen darstellt.456 Im Kern umfasst das Requirements Engineering vier Aktivitäten.457 Dazu gehören die (1) Anforderungserfassung, (2) -analyse, (3) -spezifikation sowie schließlich die (4) Validierung und Verifizierung der Anforderungen. Der Ablauf dieser Aktivitäten erfolgt jedoch typischerweise nicht in Form eines sequenziellen Prozesses. Vor allem für die Entwicklung komplexer Systeme handelt es sich vielmehr um einen inkrementellen und iterativen Prozess, der je nach Bedarf mehrere Male zu durchlaufen ist, bis die

453

Typische Mechanismen zur zielgerichteten Steuerung der Durchführung eines Prozesses sind etwa Workflowsteuerungen (vgl. Eckert et al. (2003), S. 101). Vgl. etwa Mantel et al. (2004), S. 33-34; Eckert et al. (2003), S. 100-102; Österle et al. (1991), S. 142-143 insbesondere die dort enthaltenen technischen Realisierungsmöglichkeiten und den Vorschlag zur Realisierung. 455 Vgl. Holten (2003), S. 42. 456 Vgl. Graaf et al. (2003), S. 64. 457 Vgl. hierzu und im Folgenden Nuseibeh/Easterbrook (2000), S. 35-46; Sommerville (2001), S. 131-155; Parviainen et al. (2003), S. 12-37. 454

174

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

finalen Anforderungen an das zu entwickelnde System erfasst wurden (vgl. Abb. 4.4.4.1/2).458 akzeptierte Systemanforderungen 4

Anforderungsvalidierung und Verifizierung

1

3 Anforderungsermittlung

Anforderungsdokumentation 2 Anforderungsanalyse

Abb. 4.4.4.1/2: Aktivitäten der Anforderungsermittlung

Im Folgenden werden die einzelnen Aktivitäten des Requirements Engineering kurz skizziert und im Hinblick auf eine nötige Modifizierung für die Anwendungssystemintegration in Unternehmensnetzwerken untersucht. Ausgangspunkt des Requirements Engineering ist die Anforderungsbestimmung als erste Aktivität. Ausgehend von den zu ermittelnden Projektzielen sind für die Anforderungsbestimmung zunächst sämtliche Projektbeteiligten zu bestimmen.459 Dies erfolgt durch die Betrachtung aller potenziell relevanten Blickwinkel (Viewpoints) auf das Projekt, von denen auf die zu berücksichtigenden Projektbeteiligte zu schließen ist. Ausgehend von den ermittelten Projektbeteiligten ist schließlich die Ist-Situation neutral und bewertungsfrei zu erheben und im Hinblick auf Problemfelder, Optimierungsansätze und Visionen zu untersuchen. Daraus lassen sich die angestrebten Ziele der zukünftigen Lösung definieren, in der – wenn auch zu diesem Zeitpunkt noch in grob definierter Form – die Anforderungen enthalten sind, die den Ausgangspunkt für die weiteren Aktivitäten bilden.460 Im Rahmen der Anforderungsanalyse als zweite Aktivität des Requirements Engineering Prozesses sind die zuvor unformatiert gesammelten Anforderungen zu begutachten. Aufgrund der unterschiedlichen Projektbeteiligten und der Vielzahl der sich daraus ergebenden Anforderungen sind diese jedoch häufig widersprüchlich oder

458

Vgl. Hofmann (2000), S. 27-29. Projektbeteiligte (eng. Stakeholder) sind alle Akteure, die über Kenntnisse über das Einsatzgebiet des Systems verfügen direkten oder indirekten Einfluss auf Systemanforderungen haben (vgl. u. a. Blyth (1999), S. 288-289). Typische Beteiligte sind entsprechend Endbenutzer, Entwickler, Experten des Anwendungsbereichs oder das Management. 460 Vgl. Rupp (2004), S. 115; Donzelli (2004), S. 16-17. 459

Techniken

175

konfliktär. Nur unzureichend gerecht werden sie mitunter ebenso übergeordneten Anforderungen, etwa allgemeinen Projektanforderungen eines Unternehmens, die für sämtliche Projekte bestehen, wie beispielsweise eine kosteneffiziente Systementwicklung oder bestehende rechtliche Normen. Zur Bereinigung solcher Problembereiche wird im Rahmen der zweiten Aktivität des Requirements Engineering eine vertiefende Anforderungsanalyse vorgenommen. Durch die Klassifizierung und Priorisierung deckt die Analyse meist eine bedeutende Anzahl von konfliktbehafteten Anforderungen auf oder solche, die aufgrund von Kosten- und Zeitbeschränkungen im Rahmen der Systementwicklung nicht berücksichtigt werden können.461 Der Analyse folgt die Anforderungsspezifikation. Diese beinhaltet eine detaillierte Dokumentation der Anforderungen in strukturierter Form und möglichst nach einem vorgegebenen Schema.462 Die Anforderungsspezifikation beinhaltet neben der exakten Formulierung der Einzelanforderungen ebenfalls eine Unterscheidung zwischen notwendigen und wünschenswerten Anforderungen sowie die Beschreibung von Zusammenhängen zwischen den Einzelanforderungen.463 Um zu gewährleisten, dass die Validierung der Anforderungen auch durch Projektbeteiligte ohne technischen Hintergrund erfolgen kann, ist die Spezifikation der Anforderungen in natürlicher Sprache zu verfassen. Abgeschlossen wird der Requirements Engineering Prozess schließlich durch die Validierung und Verifizierung der in der vorläufigen Spezifikation enthaltenen Anforderungen einer Lösung.464 Die Validierung zielt vor allem auf die Überprüfung ab, inwiefern die ermittelten Anforderungen mit den Bedürfnissen der Projektbeteiligten im Einklang stehen. Hingegen steht bei der Verifizierung die Kontrolle der Vollständigkeit und Widerspruchsfreiheit der spezifizierten Anforderungen im Vordergrund. Durch unterschiedliche Prüfungen soll diese Aktivität Fehler im Anforderungsdokument, etwa im Hinblick auf die Gültigkeit, Konsistenz und Vollständigkeit sowie Realisierbarkeit der Anforderungen aufdecken.465 Die Anforderungen, die diesen Prüfungen standhalten, gehen schließlich als abgestimmte Anforderungen in die finale Spezifikation der Lösung ein. Grundsätzlich ähnelt die Ermittlung von Anforderungen für Anwendungssysteme derjenigen von Integrationslösungen.466 Jedoch ist die Anforderungsermittlung für den

461 462 463 464 465 466

Vgl. Parviainen et al. (2005), S. 6. Vgl. Balzert (2000), S. 64-65. Vgl. Partsch (1991), S. 44; Parviainen et al. (2005), S. 5-6. Vgl. Hofmann/Lehner (2001), S. 59; Boehm (1984), S. 75-88. Vgl. Sommerville (2001), S. 148. Vgl. Holten (2003), S. 41-42; Linthicum (2000), S. 92.

176

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Einsatz bei der Anwendungssystemintegration in Unternehmensnetzwerken zu erweitern. Die erste Erweiterung betrifft die Festlegung der Viewpoints zur Anforderungsbestimmung. So ist dabei neben den Rollen der Projektbeteiligten, wie etwa Nutzer oder IT-Verantwortlicher, ebenfalls ihre Zugehörigkeit zu den vom Integrationsbereich betroffenen Netzwerkpartnern zu berücksichtigen. Entsprechend ist zu gewährleisten, dass nicht nur Nutzer der integrierten Lösung eines Netzwerkspartners an der Ermittlung der Anforderungen beteiligt sind, sondern im Idealfall auch Nutzer sämtlicher Partnerunternehmen des Netzwerks.467 Die zweite Erweiterung bezieht sich auf das Vorgehen zur Ermittlung der Anforderungen. Ausgangpunkt ihrer Ermittlung sind die Integrationsziele, die sich aus der Analyse der Ist-Situation ergeben.468 Entsprechend orientiert sich die Ermittlung des Zielsystems vorrangig an der Optimierung des Informationsflusses im Netzwerk und den damit entstehenden vorteilhaften Kosten-, Zeit- und Qualitätseffekten. Hingegen treten klassische Anforderungen der Anwendungssystementwicklung in den Hintergrund, wie etwa bei der Ableitung von bisher nicht vorhandenen und im Integrationsbereich nicht vorhergesehenen Funktionen oder Anforderungen an die grafische Benutzeroberfläche. Die dritte Erweiterung für die Anforderungsermittlung der Anwendungssystemintegration bezieht sich auf die Schwachstellenermittlung der Ist-Situation. So beziehen sich die Schwachstellen explizit auf den Integrationsbereich. Entsprechend sind bei der Analyse insbesondere integrationsspezifische Schwachstellen zu ermitteln. Diese umfassen vor allem mögliche Datenredundanzen oder fehlende Daten, bestehende Medienbrüche, Doppel- und Mehrfacharbeiten sowie die Bearbeitungszeit der zwischenbetrieblichen Aufgaben.469 Schließlich sind bei der Validierung der ermittelten Anforderung möglicherweise unterschiedliche Einschätzungen der Netzwerkpartner adäquat zu berücksichtigen. Demzufolge hat die Technik der Anforderungsermittlung für Netzwerke geeignete Mechanismen bereitzustellen, welche die Selbständigkeit der Netzwerkpartner gewährleisten.

467 468 469

Vgl. auch Kapitel 4.6.2. Vgl. Mantel et al. (2002), S. 13-14; Gassner (1996), S. 166-167. Vgl. Petri (1990), S. 158.

Techniken

4.4.4.2

177

Vorgehen

Die Technik „Integrationsspezifikation“ lehnt sich an die oben beschriebenen Aktivitäten des Prozesses der Anforderungsermittlung an. Abb. 4.4.4.2/1 fasst die Vorgehensschritte und Ergebnisdokumente der Technik zusammen. nötige Input-Dokumente

• Verabschiedete Integrationsbereiche

Vorgehen 1.

Ermittlung der Integrationsvision

2.

Ableitung der Integrationsanforderung

3.

Anforderungsanalyse und -spezifikation

4.

Validierung der Anforderungsspezifikation

• System-Prozess-Matrix • Schnittstellenanalyse

erhaltene Ergebnisdokumente

• Integrationsvision • Viewpointübersicht • Anforderungsspezifikation

Abb. 4.4.4.2/1: Vorgehensschritte und Ergebnisdokumente der Integrationsspezifikation

Schritt 1: Ermittlung der Integrationsvision Zur Abgrenzung der Integrationsbereiche ist im ersten Schritt die Integrationsvision zu bestimmen.470 Diese dient im weiteren Verlauf der Technik als Orientierungshilfe zur Unterstützung der Spezifikation des Integrationsbereichs. Vergleichbar mit spezifischen Zielen für ein spezielles Anwendungssystem sind für die Vision jeweils Integrationsziele für die einzelnen Integrationsbereiche zu ermitteln. Sämtliche in den weiteren Schritten der Technik ermittelten Spezifikationen eines Integrationsbereichs sind an der Integrationsvision zu messen. Entsprechend bedarf es einer verhältnismäßig globalen Vision, um den Lösungsraum zu diesem Zeitpunkt nicht unnötig einzuschränken. Ebenfalls dienen diese globalen Ziele einer Integrationslösung im späteren Verlauf der Technik zur Priorisierung der aufgedeckten Anforderungen. Den Ausgangspunkt der Ermittlung der Integrationsvision bildet die Schlüsselfrage nach den sich ergebenden, gewünschten Veränderungen der Prozessabläufe aufgrund der erfolgreichen Durchführung des Integrationsprojekts.471 Weitere Ideenquellen zur Ermittlung der Integrationsziele bilden die Fragen nach den (1) spezifischen Aspekten aufgrund derer eine Notwendigkeit für das Integrationsprojekt besteht, (2) Akteuren, die erwartungsgemäß vom Integrationsprojekt profitieren werden sowie die Frage, in (3) welcher Weise sie von der Lösung profitieren. Die Beantwortung der

470

471

Vgl. Gassner (1996), S. 166-167; Petri (1990), S. 155. Für die Bedeutung der Ziele als Ausgangspunkt im Rahmen des Requirements Engineering vgl. etwa Ebert (2005), S. 87-90; Rupp (2004), S. 115; Kotonya/Sommerville (2002), S. 57; IEEE (1998a), S. 15. Vgl. hierzu und im Folgenden Ebert (2005), S. 87-90.

178

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Frage nach (4) möglichen Aspekten, die zukünftig durch den Einsatz der integrierten Lösung vermieden werden sollen bildet ebenfalls eine Ideenquelle zur Integrationszielermittlung. Mit (1) Quantifizierbarkeit, (2) Zeitbezug und (3) realistischer Zielsetzung sind drei Anforderungen an die zu ermittelnde Integrationsvision zu beachten:472 Die Quantifizierbarkeit als erste Anforderung zielt auf die Berücksichtigung eindeutiger, möglichst überprüfbarer Vorgaben an die Integrationslösung im Rahmen der Zielermittlung. Der Zeitbezug der Integrationsvision als zweite Anforderung bezieht sich hingegen auf eine einzubeziehende zeitliche Vorgabe, wann die Vision erreicht werden soll. Schließlich ist die ermittelte Integrationsvision im Hinblick auf ihre tatsächliche Erreichbarkeit zu überprüfen. Entsprechend sind vor dem Hintergrund der realistischen Zielsetzung als dritte Anforderung an die Integrationsvision utopische Zielvorstellungen zu vermeiden. Die Ermittlung der Integrationsvision endet mit deren Ausformulierung und Verabschiedung durch das Netzwerk. Wie beschrieben bildet die so ermittelte und formulierte Vision die Grundlage für die weitere Spezifikation der Integrationslösung. Als grober Rahmen ist dafür ebenfalls die angestrebte Integrationsarchitektur zu definieren. Anhaltspunkte dazu lassen sich aus der Identifizierung der Integrationsbereiche entnehmen. So spricht das weitgehende Fehlen einer Anwendungssystemunterstützung vollständiger Prozesse für eine Integration durch die Integrationsarchitektur Applikations-Sharing. Dies entspricht der klassischen ex-ante Integration, bei der die Integration vor der Implementierung eines Anwendungssystems erfolgt.473 Finden sich innerhalb der Schnittstellenanalyse hingegen Output- und Input-Systeme, die auf Basis einer 1:1-, 1:n-, n:1- sowie n:m-Basis Informationsobjekte im Rahmen der Netzwerkprozesse austauschen, so sind diese Integrationsbereiche typischerweise durch die Applikations-Kommunikation als weitere Integrationsarchitektur zu schließen. Dies entspricht der klassischen ex-post Integration, bei der physisch getrennte Anwendungssystemen durch die Bildung geeigneter Schnittstellen ein teil- bzw. vollautomatischer Austausch von Informationsobjekten ermöglicht wird.474 Ebenfalls lässt sich die mögliche Integrations-Architektur des Daten-Sharings aus der Schnittstellenanalyse entnehmen. Sie liegt beispielsweise vor, wenn Input-Systeme auf eine einheitliche Datenbasis zugreifen müssen.475 Kennzeichen dieses Integrationsbereichstyps liegen vor, sofern die Schnittstellenanalyse Hinweise auf fehlende Output-

472 473 474 475

Vgl. Gassner (1996), S. 166; Rupp (2004), S. 130-131. Ähnlich Koreimann (2000), S. 242. Vgl. Kaib (2002), S. 20. Vgl. Mantel/Schissler (2002), S. 171-172. Vgl. Schräder (1996), S. 117.

Techniken

179

Systeme bei vorhandenen Input-Systemen gibt und die Bildung einer gemeinsamen Datenbasis Vorteile verspricht (vgl. Abb. 4.4.4.2/2). Typisches Szenario für das Applikations-Sharing

Typisches Szenario für die Applikations-Kommunikation

Prozesse

AS NW 3 = = = NW = AS =

Inputsysteme 4

Kommunikationsbeziehung 1

nicht beteiligte Netzwerkpartner NW setzt AS für Hauptfunktion ein NW setzt AS für Nebenfunktion ein Netzwerkpartner Anwendungssystem

A 2 3

NW 1 NW 2 NW 3

AS 1

AS 2

AS 3

Inputsysteme

NW 4

NW 5

NW 6

AS 4

AS 5

AS 6

A A A

A A

3

A

3 A

Kommunikationsbeziehung 2

Outputsysteme

AS NW 2

3

Outputsysteme

AS NW 1

2 Prozesse mit geringer AS-Unterstützung

1

Typisches Szenario für das Daten-Sharing

NW 4

NW 5

NW 6

AS 4

AS 5

AS 6

NW 1

-

2

2

2

NW 2

-

2

2

2

NW 3

-

2

2

2

= Automatisierungspotenzial zwischen den AS = fehlendes Anwendungssystem = bereits automatisierte Übertragung der Informationsobjekte

Abb. 4.4.4.2/2: Typische Szenarien zur Bestimmung der Integrationsarchitektur

Da im Rahmen der weiteren Schritte zur Integrationsspezifikation weitere Akteure beteiligt sind – typisch sind etwa Mitarbeiter der Netzwerkpartner in den jeweiligen Fachbereichen, externe Systementwickler oder unter Umständen Kunden des Netzwerks – sollte die formulierte Vision möglichst einfach zu kommunizieren sein. Zu erreichen ist dies durch die Verwendung von Metaphern, die den Kern der Integrationslösung prägnant und möglichst in einem Satz anschaulich verdeutlichen sollen.476

Schritt 2: Ermittlung der Integrationsanforderungen Für die Ermittlung der Anforderungen an die Integrationslösung sind zunächst die relevanten Akteure aufzudecken, die von der Integrationslösung betroffen sind.477 Kennzeichen verschiedener Projektbeteiligter sind typischerweise unterschiedliche Sichtweisen auf die Integrationslösungen, etwa aufgrund unterschiedlicher Meinungen, Interessen und Standpunkte (Viewpoints). Aufgrund dieser verschiedenen Sichtweisen ergibt sich eine Vielzahl von und unter Umständen konkurrierenden Anforderungen an die Integrationslösung, die möglichst vollständig für eine exakte Spezifikation der Integrationslösung zu erfassen sind.478 Als Viewpoint ist folglich ein zu berücksichtigender Projektbeteiligter und seine individuelle Sichtweise auf die Integ-

476 477

478

Vgl. Rupp (2004), S. 118. Betroffen sind die Projektbeteiligten, wenn sie etwa die Integrationslösung nutzen, entwickeln, warten oder für die damit verbundenen Kosten aufkommen. Vgl. Sommerville (2001), S. 136.

180

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

rationslösung zu bezeichnen.479 Das viewpointorientierte Vorgehen und die damit verbundene Berücksichtigung möglichst aller Sichtweisen auf die potenzielle Integrationslösung erlaubt eine systematische und strukturierte Erfassung der Anforderungen. Dazu sind zunächst die relevanten Viewpoints zu ermitteln. Unter Zuhilfenahme von abstrakten Viewpointklassen lässt sich die Identifikation von relevanten Viewpoints für die Integrationslösung erleichtern. Zur Strukturierung dieser abstrakten Viewpointklassen wird in direkte und indirekte Viewpoints als potenzielle Quellen für Viewpoints unterschieden, denen jeweils ein Set abstrakter Viewpointklassen zugeordnet ist.480 Abstrakte Viewpointklassen der direkten Viewpoints bilden die Projektbeteiligten, die unmittelbar das integrierte System nutzen bzw. mit dessen Implementierung und Betrieb beauftragt sind.481 Anhaltspunkte zur Ermittlung dieser Viewpoints finden sich in den zwei Dokumenten System-Prozess-Matrix sowie Schnittstellenanalyse, beide jeweils aus der zweiten Technik der Methode, anhand derer die Integrationsbereiche im Netzwerk identifiziert werden. Daraus lassen sich die von einem Integrationsbereich betroffenen Partnerunternehmen ermitteln. Ausgehend von diesen sind zur Bestimmung der direkten Viewpoints die zukünftigen und derzeitigen Nutzer der integrierten Lösung aufzudecken sowie das für die Nutzer verantwortliche Management innerhalb der betroffenen Netzwerkpartner und die relevanten IT-Bereiche.482 Ebenfalls stehen Viewpoints, die mit der Implementierung, Einführung und dem Betrieb beschäftigt sind und sich unter Umständen nicht aus den Dokumenten ergeben, in direktem Bezug zur Integrationslösung.483 Sie sind ebenfalls im Rahmen der Ermittlung der direkten Viewpoints zu bestimmen. Indirekte Viewpoints stehen hingegen nicht in direktem Bezug zur integrierten Lösung, beeinflussen jedoch trotzdem deren Einsatz und Entwicklung und sind somit auch bei der Anforderungsermittlung zu berücksichtigen.484 Die Ermittlung der indirekten Viewpoints erfolgt durch systematische Eliminierung der durch die Integrationslösung nicht betroffenen abstrakten Viewpointklassen gemäß Abb. 4.4.4.2/3. Die übrig gebliebenen abstrakten Klassen sind im Anschluss systematisch auf die entsprechenden Viewpoints zu untersuchen.

479 480 481

482

483

484

Vgl. Goeken (2004), S. 171. Vgl. Hull et al. (2005), S. 60. Die abstrakten Viewpointklassen sind entsprechend die Nutzer, Entwickler und Administratoren des Systems (vgl. Kotonya/Sommerville (1996), S. 5-18). Mittels Befragung dieser Nutzer können darüber hinaus weitere Viewpoints aufgedeckt werden (vgl. Rupp (2004), S. 119). So finden sich relevante Viewpoints außerhalb der von der Integrationslösung betroffenen Netzwerkpartner, wie etwa der Netzwerkkoordinator oder externe Projektbeteiligte (vgl. Sommerville (2001), S. 135-136). Indirekte Viewpoints ergeben sich etwa aus bestehenden Normen, Standards oder sonstige Richtlinien des Netzwerks (vgl. Hull et al. (2005), S. 60).

Techniken

181

indirekte Viewpoints

Systeme

Netzwerk- und Partnerorganisation

Umgebung

rechtliches Umfeld

tech. Standards

Normen

sonst. Personen

Gesetzgebung

Schnittstellen

Richtlinien

sonst. Systeme

Richtlinien

Wartung

Standards

Abb. 4.4.4.2/3: Abstrakte Klassen indirekter Viewpoints485

Die ermittelten direkten und indirekten Viewpoints sind schließlich schriftlich zu erfassen. Dies erfolgt in Form einer Viewpointübersicht, in der die Bezeichnung des Viewpoints, dessen Beschreibung, eine Begründung über die Auswahl und, sofern möglich, dessen Wissensgebiet enthalten ist. Anhand der Übersicht erfolgt schließlich die finale Auswahl der Viewpoints, welche die entscheidungsbefugten Vertreter der Partnerunternehmen vornehmen.486 Ausgehend von den relevanten Viewpoints sind schließlich die Anforderungen an die Integrationslösung zu ermitteln. Die Aufdeckung der Anforderungen für die direkten Viewpoints wie Nutzer, Entwickler und Management erfolgt durch die Durchführung einer Ist-Analyse.487 Diese werden durch eine detaillierte Beleuchtung der jeweiligen Integrationsbereiche erhalten. Zu untersuchen sind dabei die vom Integrationsbereich betroffenen Bestandteile bzw. bereits eingesetzten Systeme sowie ihr Zusammenspiel. Für eine strukturierte Analyse der Ist-Situation sind die zentralen Eckpunkte im Hinblick auf die statischen Bestandteile, das dynamische Verhalten und die kausalen Zusammenhänge innerhalb des Integrationsbereichs sowie die integrationsrelvanten Aspekte der Datenverarbeitung zu ermitteln.488 Im Hinblick auf die zu erfassenden statischen Bestandteile ist insbesondere zu untersuchen, welche (1) auszuführenden Tätigkeiten, (2) zu verarbeitenden Dateninhalte, gegebenenfalls kombiniert mit (3) weiteren Informationsquellen, und (4) eingesetzten (technischen) Hilfsmittel neben den Anwendungssystemen innerhalb des Integrationsbereichs auftreten. Die Erfassung dieser Aspekte erfolgt typischerweise

485 486 487 488

Vgl. Kotonya/Sommerville (1996), S. 5-18. Vgl. Rupp (2004), S. 123. Vgl. Kotonya/Sommerville (2002), S. 58; Balzert (2000), S. 101; Schumann et al. (1994), S. 84-86. Vgl. Schulze/Koller (2002), S. 118-120 sowie hierzu und im Folgenden Kimm et al. (1979), S. 4950; Partsch (1991), S. 40; Petri (1990), S. 156; Emmelhainz (1990), S. 130.

182

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

durch Beobachtung der von einem Integrationsbereich betroffenen Personen sowie den integrationsrelevanten Tätigkeiten, die sie durchführen. Neben den statischen Bestandteilen ist das dynamische Verhalten innerhalb des Integrationsbereichs für die Ist-Analyse zu erfassen. Zu untersuchen sind dafür (1) die integrationsrelevanten Bearbeitungsschritte in ihrer zeitlichen (2) Abfolge sowie (3) die jeweiligen Orte ihrer Verrichtung. Darüber hinaus ist im Hinblick auf die Erfassung der dynamischen Aspekte eines Integrationsbereichs der darin bestehende (4) Informationsfluss von Bedeutung. Dazu sind insbesondere (4) Herkunft und Verwendung der relevanten Daten sowie die (5) relevanten Datenbearbeitungsschritte in ihrer zeitlichen Abfolge zu analysieren. Durch die Untersuchung der kausalen Zusammenhänge als weiterer Aspekt der IstAnalyse lassen sich (1) Ursachen und mit ihnen verbundene Folgen eines vom Integrationsbereich betroffenen Vorgangs ermitteln. Neben beabsichtigten sind ebenso unbeabsichtigte Ergebnisse eines Vorgangs sowie die (2) ursächlichen Zusammenhänge verschiedener Vorgänge aufzunehmen. Schließlich ist der Integrationsbereich im Rahmen der Ist-Analyse im Hinblick auf integrationsrelevante Aspekte der Datenverarbeitung zu untersuchen. Im Fokus dieser Analyse stehen dabei Fragen nach (1) der Art der Datenweitergabe bzw. des Datenempfangs, womit die Schnittstellen und Datenübertragungsmedien erfasst werden. Ebenfalls zu erfassen ist (2) die Leistungsfähigkeit der Datenverarbeitung. Zu analysieren sind dazu die Bearbeitungs- Transport- und Liegezeiten der relevanten Daten sowie der derzeitige Durchsatz. Zur Ermittlung der relevanten Aspekte der Datenverarbeitung innerhalb eines Integrationsbereichs sind ebenfalls (3) die Frequenz, Häufigkeit und Regelmäßigkeit der datenverarbeitenden Schritte sowie (4) die Möglichkeiten und Wahrscheinlichkeiten von Fehlfunktionen zu erfassen. Anhand der Ist-Analyse erfolgt schließlich die Ermittlung der Anforderungen an die Integrationslösung. Dazu ist die Ist-Analyse im Hinblick auf drei Kriterien zu beurteilen:489 Als erstes Kriterium sind die derzeitigen Stärken der Lösungen, des Vorgehens und der eingesetzten Systeme innerhalb des Integrationsbereichs aufzudecken. Diese Kriterien beinhalten Aspekte, die aus Sicht der Betrachter ohne Veränderungen in die neue Integrationslösung fließen sollen und entsprechend als „guter Ist-Teil“ bezeichnet werden. Neben dem guten Ist-Teil ist aus der Ist-Analyse zu ermitteln, welche Aspekte nicht in die angestrebte Integrationslösung fließen, wobei diese Elemente im Folgenden als „obsoleter Ist-Teil“ bezeichnet werden. Schließlich sind anhand der Ist-Analyse die Schwachstellen im Hinblick auf den bestehenden Integrationsbereich zu ermitteln. Schwachstelen sind solche Teile der Ist-Situation, die aus Sicht

489

Vgl. im Folgenden Böhm et al. (1996), S. 28-29.

Techniken

183

des jeweiligen Viewpoints grundsätzlich als relevant für die angestrebte Integrationslösung erscheinen, derzeit jedoch mit Mängeln versehen und entsprechend verbesserungsfähig sind. Mit ablauforientierten, organisatorischen und technischen Schwachstellen lassen sich drei unterschiedliche Typen unterscheiden, vor deren Hintergrund die Ist-Analyse zu beurteilen ist:490 Im Hinblick auf die ablauforientierten Schwachstellen ist zum einen zu untersuchen, inwiefern innerhalb des Integrationsbereichs (1) redundante Datenhaltung auftritt und wo grundsätzlich benötigte (2) Daten oder (3) Funktionen der Datenverarbeitung fehlen. Festzuhalten sind zum anderen bestehende (4) Medienbrüche bei der Datenübermittlung. Im Rahmen der Erfassung ablauforientierter Schwachstellen sind ebenfalls (5) redundante Bearbeitungsschritte bei der Datenerfassung, -abstimmung und -überprüfung zu beleuchten, ebenso wie (6) hohe Liege-, Bearbeitungs- und Transportzeiten. Für die Ermittlung der aufbauorganisatorischen Schwachstellen ist der Integrationsbereich im Hinblick auf die (1) Abteilungsorganisation verbunden mit der Aufgabenverteilung, Personal- und Sachmittelausstattung, (2) bestehenden Richtlinien und Vorschriften, die Schwachstellen (3) des Berichtwesens sowie hinsichtlich (4) SollSchnittstellen zu anderen organisatorischen Bereichen des Netzwerks, wie etwa zum Netzwerkcontrolling zu überprüfen. Schließlich sind für die Erfassung der technischen Schwachstellen innerhalb des Integrationsbereichs die Hard- und Softwareausstattung der betroffenen Netzwerkpartner sowie die) IT-Kompetenzen der vom Integrationsbereich betroffenen Mitarbeiter bei den Netzwerkpartnern zu beleuchten. Wie beschrieben sind ausgehend von den Integrationszielen aus dem ersten Schritt sowie den Ergebnissen der Ist-Analyse und den aufgedeckten Schwachstellen im Folgenden die Anforderungen an die Integrationslösung aus Sicht der ermittelten Viewpoints im Sinne einer Soll-Integrationslösung aufzustellen. In Anlehnung an die Differenzierung unterschiedlicher Komponenten der Ist-Analyse beinhaltet die SollIntegrationslösung mit so genannten neuen Elementen, ursprünglichen Elementen sowie verbesserten Elementen grundsätzlich drei Anforderungs-Bestandteile, die durch verschiedene Vorgehensweisen abzuleiten sind (vgl. Abb. 4.4.4.2/4).491

490 491

Vgl. Becker et al. (2005), S. 89; Schulte-Zurhausen (2002), S. 353; Petri (1990), S. 158. Vgl. Böhm et al. (1996), S. 28-29.

184

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

aus Integrationsziel ableiten

verwerfen

Ist-Situation eines Integrationsbereichs

Soll-Situation eines Integrationsbereichs

obsoleter Ist-Teil

neue Elemente

guter Ist-Teil

übernehmen

Ist-Teil mit Schwachstellen

ursprüngliche Elemente

verbesserte Elemente

Schwachstellen beheben

Abb. 4.4.4.2/4: Anforderungsermittlung anhand der Ist-Situation und dem Integrationsziel492

Zur Erfassung der Anforderungen, die sich aus den neuen Elementen ergeben, stellt das Integrationsziel den Ausgangspunkt dar. Vor dessen Hintergrund sind – etwa durch das Führen von offenen Interviews oder den Einsatz von Kreativtechniken wie dem Brainstorming – die Anforderungen an die zukünftige Integrationslösung aus Sicht der betroffenen Viewpoints zu ermitteln.493 Strukturieren lässt sich die Anforderungsermittlung durch die differenzierte Bestimmung von potenziellen Diensten der Integrationslösung, möglichen Dateneingaben, nicht-funktionalen Anforderungen, Steuerereignissen sowie Ausnahmen.494 Ein typisches Beispiel solcher Anforderungen könnte die automatische Erfassung von Kennzahlen zu einem Prozess, wie die Anzahl der Transaktionen oder die durchschnittliche Dauer des Prozesses darstellen, die in der Ist-Situation nicht erfasst werden. Neben den Anforderungen aus den neuen Elementen der Integrationslösung sind Anforderungen aus den bestehenden und den zu verbessernden Elementen der IstSituation aufzunehmen.495 Die Ermittlung der Anforderungen, die sich aus den ursprünglichen Elementen ergeben, erfolgt anhand der Analyse der Ist-Situation. Dabei ist aus Sicht der Viewpoints zu erfassen, welche derzeitigen Bestandteile des jeweils untersuchten Integrationsbereichs ohne Änderung innerhalb der angestrebten Integrationslösung zu berücksichtigen sind. Von Bedeutung sind dabei etwa derzeitig ver-

492 493

494 495

In Anlehnung an Böhm et al. (1996), S. 29. Vgl. Ebert (2005), S. 95. Neben offenen Interviews und Brainstorming findet sich in der Literatur eine Reihe von weiteren Vorgehensweisen, mit deren Hilfe sich die Aufdeckung von Anforderungen erreichen lässt. Dazu gehören etwa die Dokumentenanalyse, strukturierte Interviews, Fragebögen, Protokollanalyse, Beobachtung, Fokusgruppen, Workshops und andere mehr (vgl. Hofmann (2000), S. 31-47). Vgl. Sommerville (2001), S. 138. Vgl. Böhm et al. (1996), S. 28.

Techniken

185

wendete Funktionen oder Daten, die aus Sicht der Betrachter möglichst ohne Änderung in die zukünftige Lösung zu übernehmen sind. Schließlich sind aus Sicht der Viewpoints anhand der Schwachstellenanalyse Anforderungen zu ermitteln. Dazu ist aus Sicht der Viewpoints zu erfassen, welche Bestandteile der Ist-Situation in optimierter Form in die angestrebte Integrationslösung zu übernehmen sind. Ein typisches Beispiel solcher Anforderungen ist etwa die Möglichkeit der elektronischen Übermittlung von Dokumenten zwischen zwei Anwendungssystemen, die in der Ist-Situation lediglich in physischer Form erfolgte. Durch den vorgestellten Ansatz der Anforderungsermittlung werden die funktionalen Anforderungen typischerweise ohne Probleme aufgedeckt. Nicht-funktionale Anforderungen der angestrebten Integrationslösung hingegen werden im Rahmen der Erfassung typischerweise vernachlässigt.496 Um gleichermaßen die Identifikation der nicht-funktionalen Anforderungen zu ermöglichen, werden sie mittels eines strukturierten Katalogs zum Abschluss der Anforderungsermittlung erfasst.497 Wie beschrieben sind für Integrationslösungen grundsätzlich vier abstrakte Typen nichtfunktionaler Anforderungen zu unterscheiden. Diese umfassen (1) Flexibilität, (2) Echtzeitverhalten, (3) Integration sowie (4) Korrektheit der Integrationslösung.498 Zur ausführlichen Erfassung der unter diesen vier Anforderungstypen zusammengefassten Einzelanforderungen orientiert sich das Vorgehen an den innerhalb der ISO/IEC 9126-Norm vorgeschlagenen Merkmalen nicht-funktionaler Anforderungen.499 Im Allgemeinen umfassen diese Merkmale (1) Funktionalität, (2) Zuverlässigkeit, (3) Benutzbarkeit, (4) Effizienz, (5) Änderbarkeit und (6) Übertragbarkeit. Den Merkmalen sind zur differenzierteren Ermittlung nicht-funktionaler Anforderungen wiederum detaillierte Teilmerkmale zugeordnet (vgl. Abb. 4.4.4.2/5).500 Unter Zuhilfenahme von Kreativtechniken sind zur tatsächlichen Ermittlung für die vier Typen nicht-funktionaler Anforderungen von Integrationslösungen schließlich Flexibilität, Echtzeitverhalten, Integration und Korrektheit jeweils anhand der Teilmerkmale der ISO-Norm 9261 und der gewünschten Ausprägungen die tatsächlichen Anforderungen an die angestrebte Integrationslösung zu erfassen.501

496 497 498 499 500 501

Vgl. Ebert (2005), S. 95. Vgl. Mantel et al. (2004), S. 33-34; Eckert et al. (2003), S. 100-102. Vgl. Kapitel 4.4.4.1. Vgl. Ebert (2005), S. 99. Vgl. Hohler/Villinger (1998), S. 67. Vgl. Ebert (2005), S. 101; Mantel et al. (2004), S. 33.

186

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Merkmal

Teilmerkmale

Funktionalität

• • • • •

Richtigkeit Angemessenheit Interoperabilität Ordnungsmäßigkeit Sicherheit

Zuverlässigkeit

• Reife • Fehlertoleranz • Wiederherstellbarkeit

Benutzbarkeit

• Verständlichkeit • Erlernbarkeit • Bedienbarkeit

Effizienz

• Zeitverhalten • Verbrauchsverhalten

Änderbarkeit

• • • •

Analysierbarkeit Modifizierbarkeit Stabilität Prüfbarkeit

Übertragbarkeit

• • • •

Anpassbarkeit Installierbarkeit Konformität Austauschbarkeit

Abb. 4.4.4.2/5: Merkmale zur Identifikation nicht-funktionaler Anforderungen502

Schritt 3: Anforderungsanalyse und Spezifikation Grundsätzlich ist das Vorgehen der Anforderungsanalyse in zwei Teilkomplexe zu gliedern. Der erste Teilkomplex beschäftigt sich mit der Untersuchung der einzelnen Anforderungen im Hinblick auf möglicherweise vorhandene Problemfelder, die mit den ermittelten Anforderungen verbunden sind. Entsprechend findet in diesem ersten Teilkomplex die tatsächliche Untersuchung der Anforderungen statt. Der zweite Teilkomplex stellt eine Erweiterung der Anforderungsanalyse dar und widmet sich der Erzielung von Kompromissen aufgrund unterschiedlicher Vorstellungen von Projektbeteiligten, so dass schließlich eine gemeinsam akzeptierte Verabschiedung der ermittelten Anforderungen erfolgen kann. Die relevanten Vorgehensschritte der beiden Teilkomplexe werden im Folgenden im Detail vorgestellt: Wie beschrieben beschäftigt sich der erste Teilkomplex der Anforderungsanalyse mit der tatsächlichen Untersuchung der ermittelten Anforderungen. Das Ziel des bisherigen Vorgehens im Rahmen der Anforderungsermittlung lag in der Identifikation möglichst sämtlicher Anforderungen an die jeweils untersuchte Integrationslösung. Entsprechend sind die bis zu diesem Zeitpunkt aufgedeckten Anforderungen typischerweise mit einer Reihe von Problemen behaftet, etwa dadurch, dass sie lediglich in

502

In Anlehnung an Ebert (2005), S. 99.

Techniken

187

unstrukturierter Form vorliegen, keinerlei Hinweise über ihre Prioritäten und Zusammenhänge enthalten sowie sich unter Umständen konfliktär zueinander verhalten.503 Entsprechend den oben skizzierten Problemfeldern sind die ermittelten Anforderungen aufgrund der unstrukturierten Anforderungsermittlung im Rahmen der Analyse hinsichtlich ihrer Notwendigkeit, Konsistenz, Vollständigkeit sowie Umsetzbarkeit zu untersuchen. Die Notwendigkeit von Anforderungen wird im Hinblick auf die übergeordneten Ziele des Netzwerks sowie die jeweiligen Integrationsziele eines Integrationsbereichs hin untersucht.504 Von den Projektbeteiligten sind dazu die jeweiligen Anforderungen gemäß ihrem Beitrag zu den Netzwerkzielen und dem Integrationsziel zu klassifizieren. Möglich ist dies durch die jeweilige Einstufung der Anforderungen anhand der Kategorien „großer“ (Beurteilung mit Wert = 2), „geringer“ (Beurteilung mit Wert = 1) und „kein“ Beitrag (Beurteilung mit Wert = 1), zum einen zu den Netzwerk- und zum anderen zu den Integrationszielen.505 Erfolgen kann dies in Form einer Matrix, innerhalb der als Dimensionen die ermittelten Anforderungen etwa als Zeilen den Zielen des Netzwerks sowie dem Integrationsziel, beide als Spalten, gegenübergestellt sind. In den Schnittpunkten der Matrix ist entsprechend die jeweilige Einschätzung einzutragen. Die durch die Projektbeteiligten getrennt voneinander vorgenommene Einstufung ist schließlich zu einer netzwerkübergreifenden Klassifikation der Notwendigkeit der jeweiligen Anforderungen eines Integrationsbereichs zusammenzufassen.506 Durch die Überprüfung der Konsistenz der ermittelten Anforderung sollen zum einen Widersprüche zwischen den Anforderungen einer Integrationslösung und zum anderen sich überlagernde Anforderungen aufgedeckt werden. Möglich ist dies durch die Aufstellung einer Interaktionsmatrix innerhalb der die ermittelten Anforderungen sowohl in den Zielen als auch in den Spalten enthalten sind.507 Innerhalb sämtlicher Schnittpunkte ist von den jeweiligen Projektbeteiligten einzutragen, inwiefern die Anforderungen konfliktär zueinander stehen (Bewertung mit Wert = 1), sich überlagern (Beurteilung mit Wert = 1000) sowie voneinander unabhängig sind (Beurteilung mit Wert = 0).508 Die Einschätzung der Anforderungskonsitenz durch die einzelnen Part-

503 504 505 506

507 508

Vgl. hierzu und im Folgenden Kotonya/Sommerville (2002), S. 59. Vgl. Parviainen et al. (2005), S. 6; Kotonya/Sommerville (2002), S. 59. Ähnlich Ebert (2005), S. 59. Dieses Vorgehen folgt der bereits beschriebenen Relevanzbeurteilung der Netzwerkziele durch die Partnerunternehmen (vgl. Schritt 3 im Kapitel 4.4.1.1). Vgl. Kotonya/Sommerville (2002), S. 79. Die Vergabe von unterschiedlichen Werten für die überlagernden (Wert = 1000) und für die konfliktären (Wert = 1) Anforderungen ermöglicht durch einfache Addition der Zeilen bzw. Spalten die Erfassung der Anzahl möglicher Konflikte (der Rest nach einer Division der Spalten- bzw. Zeilensumme durch 1000) bzw. Überschneidungen (Ergebnis nach einer Division durch 1000 und anschließender Rundung auf eine volle Zahl).

188

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

nerunternehmen ist schließlich für eine netzwerkübergreifende Einschätzung zu konsolidieren. Im Hinblick auf die Überprüfung der Vollständigkeit der Anforderungen ist zu untersuchen, inwiefern die ermittelten Anforderungen vollends erfasst wurden.509 Durch diese Prüfung ist auszuschließen, dass die bereits erfassten Anforderungen keine Unklarheiten und offene Aspekte beinhalten, die eine vertiefende Analyse fordern. Eine möglichst vollständige Erfassung ist zu erreichen, indem sämtliche ermittelten Anforderungen in Form von Anforderungsformularen beschrieben werden (vgl. Abb. 4.4.4.2/6).

Anforderungsformular Bezeichnung

Anforderungsname

Begründung

Grund für die Bereitstellung der Anforderung

Spezifikation

Beschreibung der Anforderung

Betroffene Viewpoints

Liste der Viewpoints, welche die Anforderung in Anspruch nehmen

Betroffene nichtfunktionale Anforderung

Verweis auf nicht-funktionale Anforderungen, welche die Anforderung einschränken

Anbieter

Verweis auf eine Liste von Systemobjekten, welche die Anforderung bereitstellen

Abb. 4.4.4.2/6: Anforderungsformular zur Überprüfung der vollständigen Erfassung510

Schließlich sind die ermittelten Anforderungen im Hinblick auf ihre Umsetzbarkeit zu bewerten. Eingeschränkt wird die Umsetzbarkeit insbesondere durch bestehende technische Beschränkungen sowie mögliche Budget- und Zeitrestriktionen. Erfolgen kann diese Überprüfung mithilfe von Checklisten, anhand derer alle Projektbeteiligten sämtliche ermittelten Anforderungen im Hinblick auf mögliche Einschränkungen systematisch untersuchen.511 Dazu sind innerhalb einer Tabelle die Anforderungen als Zeilen und die Fragenkomplexe der Checkliste als Spalten gegenübergestellt. Innerhalb der entsprechenden Zellen sind von den Projektbeteiligten die Kommentare über potenzielle Probleme zu vermerken. Die Fragen zur Ermittlung der Budget-, Zeit- und technischen Restriktionen zielen auf die Analyse, inwiefern die Anforderungen mit den übergeordneten Zielen des Netzwerks übereinstimmen und vor dem Hintergrund des zu erwartenden Nutzens aus einer Anforderung im Verhältnis zum Auf-

509 510 511

Vgl. Balzert (2000), S. 102; Partsch (1991), S. 47-48. In Anlehnung an Sommerville (2001), S. 138. Vgl. Kotonya/Sommerville (2002), S. 78-79.

Techniken

189

wand ihrer Implementierung wirtschaftlich sowie realistisch im Hinblick auf den derzeitigen Stand der im Netzwerk eingesetzten Technologien erscheinen. Ebenfalls ist zu analysieren, inwiefern die Implementierung der Anforderung mit dem Einsatz von nicht-standardisierter Soft- oder Hardware verbunden ist.512 Wie beschrieben ist neben der reinen Untersuchung der ermittelten Anforderungen als zweiter Teilkomplex der Anforderungsanalyse ein Kompromiss zwischen den Projektbeteiligten über die in der angestrebten Integrationslösung tatsächlich enthaltenen Anforderungen zu erzielen. Dies ist nötig, da ähnlich dem Vorgehen bei der Anforderungsermittlung die bereits identifizierten Viewpoints auch für die Analyse zu berücksichtigen sind. So lässt sich sicherstellen, dass nicht im Rahmen der Anforderungsanalyse bereits ermittelte und für eine Gruppe der Projektbeteiligten als besonders wichtig erachtete Anforderungen aufgrund ihrer fehlenden Beteiligung an der Analyse gestrichen werden. Die Berücksichtigung aller relevanten Projektbeteiligten an der Anforderungsanalyse bringt jedoch Probleme mit sich. So führt die Berücksichtigung einer Vielzahl an Beteiligten zu unterschiedlichen subjektiven Vorstellungen und Ansichten, die im Rahmen der Anforderungsanalyse eingebracht werden und die für die Verabschiedung der Anforderungen in Einklang zu bringen sind.513 Um typischerweise so entstehende Konflikte zu mindern, ist die Anforderungsanalyse um eine gemeinschaftliche Aushandlung (Requirements Negotiation) der zu realisierenden Anforderungen zu erweitern.514 Dies erfolgt im Rahmen der Anforderungsanalyse durch die (1) gemeinsame Erörterung der ermittelten Anforderungen sowie die (2) Anforderungspriorisierung. Damit fokussiert der zweite Teilkomplex der Anforderungsanalyse die Erzielung eines Kompromisses zwischen den relevanten Projektbeteiligten im Hinblick auf die Anforderungen ab. Entsprechend ist dieser Teilkomplex durch die (3) Anforderungsverabschiedung als letzter Vorgehensschritt abzuschließen.515 Die aus dem ersten Teilkomplex erhaltenen Ergebnisse zur Notwendigkeit, Konsistenz, Vollständigkeit und Umsetzbarkeit der Anforderungen bilden die Grundlage für die drei Vorgehensschritte des zweiten Teilkomplexes der Anforderungsanalyse. Das Ziel der gemeinsamen Erörterung von Anforderungen liegt in der Lösung der Problemfelder und Unstimmigkeiten, die im Rahmen des ersten Teilkomplexes der

512 513

514 515

Vgl. Parviainen et al. (2005), S. 6; Ebert (2005), S. 95-96. Beispielsweise wird die Anforderung einer einfachen Systemwartung typischerweise vom ITBereich als besonders wichtig angesehen, wobei ein betroffener Fachbereich hingegen auf diese Anforderung verzichten könnte. Gerade bei Netzwerken wird dieses Phänomen durch eine Vielzahl etwa an Fachabteilungen und IT-Bereichen, die von einer Integrationslösung betroffen sein können, erheblich verstärkt. Vgl. etwa Wortmann (2001), S. 27; Parviainen et al. (2003), S. 12. Vgl. Kotonya/Sommerville (2002), S. 60.

190

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Anforderungsanalyse aufgedeckt wurden. Das Vorgehen dazu ist im Kern in zwei Teilschritte untergliedert:516 In einem ersten Schritt ist der Ursprung der Konflikte einer Anforderung im Detail vorzustellen. Daraufhin sind in einem zweiten Schritt die Projektbeteiligten aufgefordert, mögliche Ansätze zur Lösung eines entsprechenden Konfliktfeldes vorzustellen bzw. zu erarbeiten. Insbesondere sind daran die von einer Anforderung betroffenen Viewpoints zu beteiligen, die dem bereits erstellten Anforderungsformular zu entnehmen sind. Das Ziel dieses Vorgehens liegt in der Entscheidung, inwiefern Anforderungen zu ändern sind und welche Anforderungen zwingend in der Integrationslösung enthalten sein sollten, sowie auf welche Anforderung auch verzichtet werden kann. Unterstützt wird die Erörterung der Anforderungen durch eine Anforderungspriorisierung als weiterer Vorgehensschritt des zweiten Teilkomplexes der Anforderungsanalyse.517 Geeignet ist die Priorisierung insbesondere für die mit Konflikten behafteten Anforderungen. Somit lassen sich die bedeutenden von den weniger bedeutenden Anforderungen abgrenzen, womit sich der Entscheidungsprozess über die tatsächlich zu realisierenden Anforderungen erleichtern lässt.518 Im Rahmen der Priorisierung sind die Anforderungen durch die Projektbeteiligten im Hinblick auf zwei Kernaspekte zu bewerten. Zum einen ist der sich aus jeweils einer Anforderung ergebende potenzielle Nutzen für das Netzwerk abzuschätzen. Typische Aspekte zur Nutzenpriorisierung der Anforderungen bilden die Fragen nach dem erhöhten Kundennutzen durch eine Anforderung, zu erwartenden Einsparungen für das Netzwerk oder der Steigerung von Verarbeitungskapazitäten.519 Erfolgen kann die Priorisierung auf Grundlage der bereits innerhalb der Evaluation von Integrationsbereichen verwendeten Kategorien zur Ermittlung des Nutzens eines Integrationsbereichs.520 Neben der Einschätzung des mit einer Anforderung verbundenen Nutzens ist zum anderen eine technische Priorisierung der jeweiligen Anforderungen an eine Integrationslösung durchzuführen. Dabei stehen Fragen zu Machbarkeit, technischen Einschränkungen, Einflüssen auf die bestehende Anwendungssysteminfrastrukur, das Lastverhalten sowie zu erwartende Wartungsaufwendungen im Vordergrund.521 Im Rahmen der tatsächlichen Priorisierung sind die Anforderungen in Form von zwei Matrizen zunächst den Nutzenkategorien sowie im Anschluss den technischen Einfußfaktoren gegenüberzustellen. In den jeweiligen Schnittpunkten der Matrizen ist von den Projektbeteiligten anzugeben, inwiefern ein hoher, ein niedriger oder gar kein Einfluss 516 517 518 519 520 521

Vgl. Kotonya/Sommerville (2002), S. 81. Vgl. im Folgenden Ebert (2005), S. 96 sowie 101. Vgl. Berander/Andrews (2005), S. 70. Vgl. Ebert (2005), S. 166. Vgl. Kapitel 4.4.3.2. Vgl. Ebert (2005), S. 166.

Techniken

191

einer Anforderung auf den jeweiligen Aspekt besteht.522 Die Einzelbewertungen der Aspekte sind schließlich für jeweils eine Zeile der Matrix aufzusummieren und lassen sich im Anschluss in ein zusammenfassendes Priorisierungsportfolio übertragen (vgl. Abb. 4.4.4.2/7). Zielkorridor

ƶ Nutzen

technische Bewertung

ƶ Anforderungen

Anforderungen

Nutzenbewertung

+

Anforderung

technische Bewertung

+

Abb. 4.4.4.2/7: Priorisierung der Anforderungen523

Abgeschlossen wird der zweite Teilkomplex der Anforderungsanalyse schließlich durch die gemeinsame Verabschiedung der vom Netzwerk gewünschten Anforderungen an eine Integrationslösung.524 Dazu ist von den Projektbeteiligten eine Übereinkunft über die durchzuführenden Aktivitäten hinsichtlich der problembehafteten Anforderungen zu treffen. Typische Aktivitäten sind die Streichung oder Änderung einer Anforderung sowie das Einholen von weiteren Informationen, um die Konflikte in einem anschließenden Durchlauf der Verhandlungen über Anforderungen auflösen zu können.

Schritt 4: Anforderungsspezifikation sowie Validierung und Verifizierung Im Anschluss an die Anforderungsanalyse erfolgt die Spezifikation der Anforderungen im Detail, worunter ihre übergreifende verbale Beschreibung gefasst wird.525 Innerhalb der Spezifikation sind entsprechend alle funktionalen und nicht-funktionalen Anforderungen zu verzeichnen. Im Kern sind die ermittelten Anforderungen bei der Erstellung der Anforderungsspezifikation zunächst (1) detailliert zu beschreiben, (2) 522

523

524 525

Vgl. etwa IEEE (1998a), S. 13. Entsprechend ist für den Einsatz der Matrizen der Wert „0“ zu vergeben, wenn die Anforderung keinen Einfluss auf den jeweiligen Aspekt hat. Der Wert „1“ hingegen ist bei einem niedrigen sowie der Wert „2“ bei einem hohen Einfluss zu vergeben. In Anlehnung an Ebert (2005), S. 168. Eine Anforderung ist höher priorisiert, je weiter rechts oben diese innerhalb Portfolios verzeichnet ist. Vgl. Balzert (2000), S. 103. Vgl. etwa Balzert (2000), S. 111. Siehe im Detail für die Spezifikation etwa Müller (1988), S. 43-47; Schnupp/Floyd (1979), S. 152-167.

192

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

systematisch zu gruppieren und klassifizieren, im Hinblick auf (3) notwendige und optionale Anforderungen zu unterscheiden sowie (4) auf Zusammenhänge zwischen den Anforderungen hin zu untersuchen.526 Anhand eines vordefinierten Gliederungsschemas ist die zusammenfassende Beschreibung der ermittelten Anforderungen und damit die Spezifikation der Integrationslösung zu unterstützen. Das Gliederungsschema fungiert dabei als Strukturierungshilfe um die ermittelten Anforderungen vollständig und verständlich zu erfassen.527 Sollte das Netzwerk bzw. einzelne Partnerunternehmen nicht bereits über ein vordefiniertes Gliederungsschema zur Anforderungsspezifikation – etwa aus vorangegangenen Softwareentwicklungsprojekten – verfügen, so lässt sich auf die innerhalb der Praxis weit verbreitete IEEE Recommended Practice for Software Requirements Specifications (Std. 830-1998) als Strukturierungsvorlage zurückgreifen (vgl. Abb. 4.4.4.2/8).528 Für die Beschreibung der funktionalen Anforderungen stehen dabei die bereits erstellten Anforderungsformulare des vorherigen Teilschritts zur Verfügung.

Kapitel

Beschreibung

Einleitung

Gibt einen Überblick über die Anforderungsspezifikation

Zusammenfassende Produktbeschreibung

Zur Beschreibung der generellen Faktoren, die Produkt sowie Anforderungen beeinflussen

Spezifische Anforderungen

Zur Beschreibung aller Details, die für den Produktentwurf benötigt werden

Inhaltsaspekte • Zielsetzung der Anforderungsspezifikation • Anwendungsbereich des Produkts • Verwendete Definitionen, Akronyme und Abkürzungen • Liste über die referenzierten Dokumente • Übersicht über Aufbau und Inhalt der Spezifikation • • • •

Produktumgebung und Schnittstellen Wesentliche Funktionalitäten des Produkts Aufstellung der potenziellen Nutzer des Produkts Aufführung der bestehenden Einschränkungen (Hardware, gesetzliche Vorgaben,...)

• Detaillierte Erfassung der Inputs und Outputs des Produkts • Beschreibung der funktionalen Anforderungen • Aufstellung bestehender Leistungsanforderungen • Aufführung bestehender Entwurfsrestriktionen (bestehende Standards, Hardware,...) • Aufstellung der gewünschten Qualitätsmerkmale (Zuverlässigkeit, Sicherheit, Wartbarkeit,...) • Weitere Anforderungen

Abb. 4.4.4.2/8: Gliederungsschema der Anforderungsspezifikation529

526 527 528 529

Vgl. Partsch (1991), S. 44. Vgl. Balzert (2000), S. 114. Vgl. Ebert (2005), S. 115. In Anlehnung an IEEE (1998b). Siehe auch Balzert (2000), S. 112.

Techniken

193

Die aufgestellte Anforderungsspezifikation ist im Anschluss zu validieren und zu verifizieren. Allgemein ist unter die Validierung die Frage gefasst, inwiefern das richtige Produkt, im Sinne von „gewünscht“, entwickelt wird. Mit der Verifikation wird hingegen untersucht, ob das Produkt richtig, im Sinne von „fehlerfrei“, ist.530 Bezogen auf die Anforderungsspezifikation ist im Hinblick auf die Validierung entsprechend zu untersuchen, inwiefern die erfassten Anforderungen tatsächlich die Integrationslösung definieren, die vom Netzwerk gewollt ist. Die Verifizierung der Anforderungsspezifikation zielt hingegen auf die Frage, inwiefern die erstellte Anforderungsspezifikation konsistent, vollständig und damit fehlerfrei ist.531 Im Gegensatz zur Anforderungsanalyse, bei der die Anforderungen für sich alleine betrachtet wurden, bezieht sich die nun vorzunehmende Validierung und Verifikation auf sämtliche Anforderungen der verfassten Spezifikation. Zur Validierung und Verifikation der Anforderungen ist insbesondere der Ansatz der Anforderungs-Review verbreitet. 532 Das Vorgehen der Anforderungs-Review gliedert sich im Kern in drei Teile, die in die Schritte (1) Vorbereitung und Review, (2) Review-Meeting und (3) Nachbereitung gegliedert sind:533 Im Rahmen der Vorbereitung als erster Teilschritt der Anforderungs-Review sind zunächst die geeigneten Gutachter zu selektieren. Diese sollten möglichst über fundiertes Wissen bezüglich des Problembereichs und damit des Anwendungsgebiets der Integrationslösung verfügen und bisher noch nicht an der Integrationsspezifikation teilgenommen haben, um aufgrund ihrer Unabhängigkeit eine möglichst objektive Anforderungs-Review durchführen zu können. Von den ausgesuchten Gutachtern wird im Anschluss ein Review der verfassten Anforderungsspezifikation vorgenommen. Dabei steht bei der Validierung der Anforderungen vor allem die Frage im Vordergrund, welche Auswirkungen die ermittelten und spezifizierten Anforderungen auf die Integrationslösung haben.534 Bei der Verifikation hingegen ist die Anforderungsspezifikation von den Gutachtern im Hinblick auf ihre (1) Verifizierbarkeit (worunter die Möglichkeit der Prüfung von Anforderung gefasst ist), (2) Verständlichkeit, (3) Nachvollziehbarkeit (da die Kenntnis über die Quelle der Anforderung typischerweise die Einschätzung ihrer Auswirkung erleichtert) sowie (4) ihre Anpassungsfähigkeit (die gewährleistet, dass die Anforderung ohne Änderungen weiterer Anforderungen zu modifizieren ist) zu untersuchen.

530 531 532 533 534

Vgl. Partsch (1991), S. 47-48. Vgl. Parviainen et al. (2003), S. 36. Vgl. Sommerville (2001), S. 147; Parviainen et al. (2003), S. 76. Vgl. im Folgenden Kotonya/Sommerville (2002), S. 90-92. Siehe auch Hofmann (2000), S. 70-71. Vgl. Sommerville (2001), S. 71.

194

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Im zweiten Teilschritt der Anforderungs-Review ist das Review-Meeting abzuhalten. Dabei werden die einzelnen Anmerkungen und Probleme zur Anforderungsspezifikation von den teilnehmenden Gutachtern der Anforderungsspezifikation gemeinsam erörtert. Das Ergebnis des Review-Meetings bildet zum einem ein Problemreport innerhalb diesem die von den Gutachtern aufgedeckten Probleme der Anforderungsspezifikation möglichst klassifiziert aufzuführen sind (etwa differenziert nach Problemtypen wie mehrdeutig bzw. unklar, unvollständig oder nicht nachvollziehbar). Das zweite Ergebnis bildet zum anderen, aufbauend auf dem Problemreport, eine gemeinsam verabschiedete Maßnahmenliste, in der die zur Lösung der Probleme innerhalb des Review-Meetings abgestimmten Vorgehensschritte beschrieben sind.535 Abzuschließen ist die Anforderungs-Review schließlich durch den dritten Teilschritt in Form der Nachbereitung. Dabei ist zu kontrollieren, inwiefern die abgestimmten Vorgehensschritte zur Korrektur der aufgedeckten Probleme der Anforderungsspezifikation vorgenommen wurden sowie eine berichtigte Anforderungsspezifikation zu erstellen. Diese wird entweder ein weiteres Mal begutachtet oder von den Gutachtern akzeptiert, womit die finale Anforderungsspezifikation verabschiedet und damit die Anforderungs-Review beendet ist. 4.4.5 Integrations-Assessment Die folgende Technik dient der wirtschaftlichen Bewertung der Integrationslösung. Dazu sind prinzipiell die Kosten der Integration zu erfassen und dem erwarteten Integrationsnutzen gegenüberzustellen. Das Ergebnis dieser Gegenüberstellung dient als wesentliche Entscheidungsgrundlage, ob die Realisierung des Integrationsprojekts vom Netzwerk vorgenommen wird.536 4.4.5.1

Ansatz

Ausgehend von den identifizierten und vom Netzwerk für relevant befundenen Integrationsbereichen wurde gemäß des bisherigem Methodenverlaufs die Anforderungsspezifikation der Integrationslösung erstellt, die den Ausgangspunkt zur wirtschaftlichen Bewertung der Integrationslösung darstellt. Unabhängig von der tatsächlichen Ausgestaltung im Detail ähneln sich Vorgehensweisen zur Wirtschaftlichkeitsbewertung von Anwendungssystemen darin, dass grundsätzlich zu ermittelnde Kosten der Investition ihrem geschätzten Nutzen gegenüberzustellen sind.537 Wesentliche Unterschiede zwischen den einzelnen Ansät-

535 536 537

Vgl. Kotonya/Sommerville (2002), S. 90. Vgl. hierzu und im Folgenden Schindler (2006), S. 39-57. Vgl. etwa Love et al. (2005), S. 569-582; Müller et al. (2003), S. 59.

Techniken

195

zen liegen vor allem in der Art, wie die jeweiligen Kosten- und Nutzengrößen erfasst bzw. kategorisiert werden.538 Stellt die Erfassung der zu erwartenden Kosten der Einführung und des Betriebs eines Anwendungssystems noch eine verhältnismäßig einfache Aufgabe dar, so zeigen sich besondere Schwierigkeiten bei der Erfassung ihrer Nutzeffekte. Hintergrund dieser Schwierigkeiten sind die typischerweise durch den Einsatz von Anwendungssystemen auftretenden, nicht-monetär erfassbaren Effekte.539 Bisherige Lösungsansätze zur Behebung dieser Schwierigkeiten finden sich innerhalb der Literatur bei der Erstellung ganzheitlicher Entscheidungsgrundlagen im Rahmen der Wirtschaftlichkeitsbeurteilung von Anwendungssystemen. Dabei sind typischerweise zunächst die monetär erfassbaren Größen zur Vorteilsermittlung gegenüberzustellen. Dies erfolgt meist unter Berücksichtigung dynamischer Verfahren der Investitionsrechnung, zu denen etwa die Kapitalwert- bzw. interne Zinsfußmethode gehören. Zur Beurteilung des Entscheidungsproblems aus einer ganzheitlichen Sicht sind anschließend die nicht-monetär erfassbaren und damit qualitativen Kriterien des Einsatzes eines Anwendungssystems hinzuzuziehen.540 Darüber hinaus wird in einem Teil der Ansätze die Gegenüberstellung der quantitativen und qualitativen Kriterien zusätzlich noch durch die Berücksichtigung der Unsicherheit ergänzt.541 Dies geschieht typischerweise durch Risikozu- und -abschläge, Szenariotechniken oder Simulationsrechnungen um die Qualität der Entscheidungsgrundlage noch weiter zu steigern.542 Verbreitete Ansätze zur Wirtschaftlichkeitsbewertung finden sich etwa in Form der Kostenvergleichsrechung, der Nutzwertanalyse, des Hedonic-Wage-Ansatzes, der Kapitalwertmethode oder der Wirkungskettenanalyse, um nur einige Beispiele zu nennen.543 Wird ein möglichst umfassendes Bild über die zu tätigende Investitionsentscheidung angestrebt, so ist aufgrund der unterschiedlichen Zielsetzung der einzelnen Ansätze die Festlegung auf einen einzigen Ansatz nicht sinnvoll.544 Vielmehr eignet sich eine Kombination der bestehenden Ansätze, um ein ganzheitliches Bild über die Investition zu erhalten. Als Auswahlkriterien dienen dabei zum einen zunächst die Zielsetzung des Ansatzes sowie der Aufwand, der mit dessen Durchführung verbunden ist. Bei der Erfassung der Kosten wird im Folgenden auf den verbreiteten Rahmen des Total-Costs-of-Ownership-Ansatzes (TCO) zurückgegriffen. Dieser vom Lebenszyklus eines Anwendungssystems ausgehende Ansatz ermöglicht mit einem ver538 539 540 541 542 543 544

Vgl. etwa zur Übersicht über bestehende Kostenkategorien Irani et al. (2006), S. 1103-1122. Vgl. Kaib (2002), S. 34. Vgl. Scheckenbach (1997), S. 41; Reichwald (1987), S. 10. Vgl. etwa Schumann (1992), S. 148. Vgl. Kaib (2002), S. 40. Zur Übersicht Nagel (1990), S. 39-163; Gehra (2005), S. 163-169. Vgl. Müller et al. (2003), S. 60; Kaib (2002), S. 40.

196

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

gleichsweise geringen Aufwand die Ermittlung sämtlicher relevanter Kosten für die Integrationslösung.545 Da sich der TCO lediglich auf die Erfassung der Kosten beschränkt, ist er für die Erfassung des Integrationsnutzens mit einem weiteren Ansatz zu kombinieren. Der Blick in die Ansätze zur Wirtschaftlichkeitsbewertung zeigt, dass sich kaum mit dem TCO zu vergleichende Ansätze hinsichtlich der Strukturierung der Nutzeneffekte finden. So scheiden zunächst Ansätze aus, die sich – wie etwa die Nutzwertanalyse – überwiegend auf qualitative Größen beschränken.546 Weitere Verfahren, wie etwa die Wirkungskettenanalyse oder der Hedonic-Wage-Ansatz kennzeichnen sich ebenfalls durch eine nicht mit dem TCO vergleichbare Systematisierung der quantitativen Kosteneffekte. Diese ist hingegen im Rahmen der Nutzenanalyse gegeben. So finden sich für diesen Ansatz detaillierte Verzeichnisse für Nutzeffekte, die sich aus dem Einsatz von Anwendungssystemen ergeben können.547 Nachteile der Nutzenanalyse finden sich indes hinsichtlich ihres Aufwands bei der Anwendung. Dieser entsteht insbesondere durch eine dabei vorzunehmende Einschätzung und Berechung der Realisierungschancen ermittelter Nutzeffekte. Zu verkleinern ist dieses Problemfeld durch die Verminderung des Erfassungsaufwands im Rahmen der Nutzenanalyse. So wird hinsichtlich des Integrationsprojekts bereits eine erste Risikoeinschätzung im Rahmen der Technik „Evaluation der Integrationsbereiche“ vorgenommen.548 Darüber hinaus lässt sich eine Risikoanpassung bei der Gegenüberstellung der Kosten- und Nutzeffekte vornehmen, etwa indem der dabei verwendete Zinssatz gemäß der Risikoeinschätzung adjustiert wird. Durch dieses Vorgehen lässt sich die Systematisierung der Nutzenanalyse verwenden, ohne dabei von dem erheblichen Aufwand der Erfassung der Nutzeneffekte zu stark beeinträchtigt zu werden. Die Gegenüberstellung der Kosten- und Nutzeneffekte erfolgt dabei im Rahmen der vorliegenden Methode mittels der Berechnung des Kapitalwerts. Trotz der darin enthalten Probleme hinsichtlich des zu verwendenden Zinssatzes bietet sich der Rückgriff auf den Kapitalwert aufgrund seiner Einfachheit und der Verbreitung in der Praxis an.549 Die Analyse der bestehenden Integrationsmethoden hat gezeigt, dass sich die darin enthaltenen Wirtschaftlichkeitsbeurteilungen stark den skizzierten allgemeinen Vorgehensweisen zur Beurteilung von Anwendungssystemen ähneln.550 Innerhalb dieser wurden zunächst ebenfalls die zu erwartenden Kosten- und Nutzeffekte ermittelt und 545 546 547 548 549 550

Vgl. Gehra (2005), S. 168; Müller et al. (2003), S. 62. Vgl. Antweiler (1995), S. 123. Vgl. Nagel (1990), S. 86. Vgl. Kapitel 4.4.3. Vgl. Nagel (1990), S. 45. Vgl. Kapitel 3.2.3 sowie 3.2.4.

Techniken

197

gegenübergestellt sowie zum Erhalt einer ganzheitlichen Entscheidungsgrundlage um qualitative Kriterien ergänzt. Des Weiteren sind für die Wirtschaftlichkeitsbewertung im Rahmen der vorliegenden Methode netzwerkspezifische Besonderheiten zu beachten. Dabei ist zu untersuchen, inwiefern die drei skizzierten allgemeinen Schritte der Wirtschaftlichkeitsbewertung für einen Einsatz in Netzwerken anzupassen sind. Allgemein ist zunächst für die Erfassung der Kosten- und Nutzeffekte zu erwarten, dass die Netzwerkpartner die anfallenden Kosten der Lösung übertreiben sowie den Nutzen, den sie aus der Lösung ziehen, untertreiben. Dieses Verhalten dient ihnen zur Minimierung der jeweiligen Einzelkosten an der Investition und birgt somit die Gefahr, dass diese aufgrund regelmäßig übertriebener Kosten und untertriebenen Nutzens durch die Partner nicht realisiert wird.551 Entsprechend hat die Integrationsmethode dieses Verhalten soweit wie möglich zu berücksichtigen, um eine weitgehend objektive Beurteilung der Investition zu gewährleisten. Demzufolge ist zunächst die Erfassung der Investitionskosten anzupassen. Grundsätzlich empfiehlt sich ihre Ermittlung unmittelbar ausgehend von dem jeweiligen Entstehungsort. Hinsichtlich der Integration in Unternehmensnetzwerken ist dabei zu berücksichtigen, dass die Kosten (ebenfalls wie die Nutzeneffekte) einer Integrationslösung sowohl zum einen auf Netzwerkebene als auch zum anderen auf der Ebene der Partnerunternehmen anfallen können.552 Somit wären im Rahmen der Kostenerfassung allgemein beide Ebenen zu berücksichtigen. Wird hingegen auf die getrennte Behandlung der Kosten auf der Ebene des Netzwerks von der Ebene der Partnerunternehmen verzichtet, so lässt sich eine ex-ante Übertreibung der Kosten von den Partnerunternehmen vermindern, da diese von der tatsächlichen Übernahme im Rahmen der Realisierung der Integrationslösung weitgehend getrennt sind. Die Zuordnung der Kosten lässt sich ex-post hingegen etwa durch das Nachweisprinzip exakter bestimmen. Ebenfalls ist ihre Verteilung durch die Kopplung an objektive Kriterien der Systemnutzung ex-post möglich, so dass eine Trennung der Ebenen im Rahmen der Kostenermittlung unnötig erscheint. Hingegen ist die Trennung der beiden Ebenen im Rahmen der Ermittlung der Nutzeffekte relevant. Dies ist insbesondere der Fall, sofern das Netzwerk von einer Übernahme der Kosten etwa nach der beteiligten Partnerzahl oder sonstiger einfacher Kriterien absieht. Durch die Trennung der Nutzeffekte auf Netzwerk- und auf Partnerebene wird entsprechend eine Grundlage für die Verrechung der anfallenden

551 552

Vgl. Hirnle (2006), S. 6. So entstehen beispielsweise im Rahmen eines Integrationsprojekts zum einem Kosten für die Schnittstellentwicklung jeweils direkt bei den Partnerunternehmen sowie für die Bereitstellung einer zentralen Integrationsplattform auf der Ebene des Netzwerks.

198

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Kosten für die Integrationslösung geschaffen, die von den Partnerunternehmen zu übernehmen sind. Dabei ist jedoch darauf zu achten, dass die Netzwerkpartner einen möglichst objektiven Nutzen der Integrationslösung auf Partnerebene angeben. Um dies zu erreichen liegt ein möglicher Schlüssel darin, die ex-ante getroffene Einschätzung der Netzwerkpartnern ex-post anhand objektiver Kriterien zu überprüfen. So lassen sich Netzwerkpartner aufdecken, die vor der Integration aufgrund einer angegebenen geringen Systemnutzung von unbedeutenden Nutzeffekten ausgegangen sind. Wird die Gegenüberstellung des angegebenen mit dem tatsächlichen Nutzen an mögliche Kompensationszahlungen gekoppelt, so ist ebenfalls zu erwarten, dass die Netzwerkpartner bereits ex-ante ihren Nutzen möglichst exakt angeben, um die Kompensationszahlungen im Nachhinein zu vermeiden. Eine weitere Modifikation des skizzierten Vorgehens „Wirtschaftlichkeitsberechnung einer Integrationslösung“ ist hinsichtlich der Risikoanpassung vorzunehmen. So stellt die Erfassung des Risikos im Rahmen der Nutzenanalyse eine erhebliche Herausforderung dar und entspricht inhaltlich nicht den Anforderungen moderner Anwendungssysteme.553 Hingegen findet sich eine effiziente Anpassung des Investitionsrisikos durch die Adjustierung des im Rahmen der Kosten- und Nutzengegenüberstellung zu verwendenden Kalkulationszinssatzes.554 Dafür sind im Kern lediglich die Einflussfaktoren für das Investitionsrisiko in Unternehmensnetzwerken zu ermitteln. Neben den allgemeinen Risiken hinsichtlich der Prognoseunsicherheit von Investitionsrückflüssen sind in Netzwerken zusätzlich die netzwerkspezifischen Risiken zu berücksichtigen. Diese lassen sich hinsichtlich zweier Aspekte strukturieren:555 So ergeben sich aus Sicht der Netzwerkpartner zum einen Risiken aus der Spezifität der jeweiligen Investition. Übertragen auf Integrationslösungen für Unternehmensnetzwerke werden spezifische Investitionen durch solche Lösungen dargestellt, die sich von den Partnerunternehmen lediglich im Kontext des spezifischen Netzwerks einsetzen lassen und außerhalb des Netzwerks weitgehend nutzlos sind. Hingegen lassen sich unspezifische Integrationslösungen ebenfalls für weitere inner- oder zwischenbetriebliche Fragestellungen nutzen. Entsprechend ist die Risikobewertung hinsichtlich der Spezifität einer Integrationslösung anzupassen. Neben der Spezifität einer Integrationslösung wirkt sich die Unsicherheit hinsichtlich der Partnerunternehmen auf die Risikoanpassung aus.556 Im Rahmen der Integration innerhalb von Netzwerken sind dabei insbesondere Fähigkeiten der Netzwerkpartner bzw. des Netzwerks hinsichtlich der Integration zu beurteilen.

553 554 555 556

Vgl. Nagel (1990), S.86. Vgl. Wöhe (2002), S. 642-643. Vgl. hierzu und im Folgenden Wohlgemuth (2002), S. 231-233. Vgl. Das/Teng (1996), S. 831.

Techniken

199

Grundsätzlich enden die klassischen Ansätze der Wirtschaftlichkeitsbewertung mit der risikoangepassten Gegenüberstellung der Kosten- und Nutzeffekte. Für die einzelnen Netzwerkpartner ist zum Erhalt einer ganzheitlichen Entscheidungsgrundlage darüber hinaus zu ermitteln, in welcher Größenordnung sie selbst entstehende Kosten zu übernehmen haben. Entsprechend ist die Wirtschaftlichkeitsbeurteilung um einen Schritt zu erweitern. Dieser dient einer möglichst objektiven Zuordnung der entstehenden Investitionskosten zu den betroffenen Netzwerkpartnern. 4.4.5.2

Vorgehen

Das Ziel der Technik liegt in der Bewertung der Wirtschaftlichkeit einer Integrationslösung. Wie in Kapitel 4.4.5.1 skizziert sind dazu zunächst die entstehenden Kosten der Integration sowie der Integrationsnutzen zu erfassen. Daraufhin lassen sich die beiden Größen gegenüberstellen, um auf die Wirtschaftlichkeit der jeweiligen Lösung zu schließen. Daraufhin wird die Technik durch die Verteilung der Investitionskosten zwischen den beteiligten Netzwerkpartnern beendet. Sämtliche Schritte der Technik sowie Input- und Ergebnisdokumente zeigt Abb. 4.4.5.2/1. nötige Input-Dokumente

• Anforderungsspezifikation

Vorgehen 1.

Ermittlung der Integrationskosten

2.

Ermittlung des Integrationsnutzens

3.

Investitionsauswahl

4.

Investitionskostenverrechnung

erhaltene Ergebnisdokumente

• Kostenaufstellung • Nutzenaufstellung • Investitionsalternativenvergleich • Verabschiedete Investitionskosten auf Partnerebene

Abb. 4.4.5.2/1: Vorgehensschritte und Ergebnisdokumente des Integrations-Assessment

Schritt 1: Ermittlung der Integrationskosten Der erste Schritt dient der Erfassung der zu erwartenden Kosten durch die Implementierung und die Nutzung bzw. Wartung der Integrationslösung. Die Kostenermittlung lehnt sich hierbei an den Total-Cost-of-Ownership-Ansatz an. Das Vorgehen dazu gliedert sich in drei Teilschritte. Zu Beginn steht, ausgehend von der Anforderungsspezifikation der vorherigen Technik, die Ermittlung der Erhebungsvoraussetzung sowie die Kostengliederung. In den anschließenden Teilschritten erfolgt daraufhin die Datenerhebung sowie schließlich die Kostenberechnung. Im ersten Teilschritt, bei dem die Erhebungsvoraussetzungen ermittelt werden, sind von den beteiligten Partnerunternehmen zunächst die zu analysierenden Investiti-

200

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

onsalternativen zu ermitteln und einzuschränken.557 Ausgangspunkt dazu sind zunächst die ermittelten Anforderungen aus der Anforderungsspezifikation. Diese dienen der Überprüfung, inwiefern potenzielle Integrationslösungen aus funktionalen sowie nicht-funktionalen Gesichtspunkten für den Integrationsbereich geeignet sind. Neben den Kriterien aus der Anforderungsspezifikation sind weitere Kriterien zur Eingrenzung möglicher Integrationslösungen von Bedeutung. In Anlehnung an den Softwareauswahlprozess umfassen diese im Kern Informationen zum (1) Anbieter der Integrationslösung (insbesondere dessen Größe und Standorte), zur (2) Produktpositionierung (insbesondere zu den Kunden, Branchen und Referenzinstallationen), zum (3) Angebot von Ausbildungen sowie Trainings (insbesondere zu Lehrgängen, Handbüchern sowie zur technischen Dokumentation) sowie zum (5) angebotenen Service des Anbieters der Integrationslösung (insbesondere zur Versionierung und zum Änderungsmanagement).558 Nach der Auswahl der aus Sicht des Netzwerks für relevant befundenen Kriterien und bei Bedarf deren Gewichtung erfolgt die jeweilige Bewertung der ermittelten Integrationslösungen.559 Ergebnis der Bewertung ist die Identifizierung prinzipiell geeigneter Integrationslösungen entsprechend den Anforderungen des Integrationsbereichs. Darüber hinaus ist vom Netzwerk im Rahmen der Ermittlung der Erhebungsvoraussetzung die Nutzungsdauer der Integrationslösung zu bestimmten. Dadurch wird der Betrachtungshorizont der Wirtschaftlichkeitsbestimmung festgesetzt. Im zweiten Schritt erfolgt die Ermittlung der Kostenkategorien, die durch den Einsatz der potenziell geeigneten Integrationslösungen für das Netzwerk anfallen. Dies erfolgt durch die Auswahl relevanter Kostenarten durch die Netzwerkpartner. Ausgangspunkt dazu sind die allgemeinen Komponenten des TCO-Ansatzes, die auf ihre Bedeutung im Hinblick auf die angestrebten Integrationslösungen zu untersuchen sind (vgl. Abb. 4.4.5.2/2).

557 558

559

Vgl. Mantel et al. (2004), S. 34. Vgl. Dangelmaier et al. (2002), S. 69-70. Die weiteren von Dangelmaier aufgeführten Kriterien insbesondere hinsichtlich des „Produkts“, dessen „Sicherheit“ und „Connectivity“ sind bereits in der Anforderungsspezifikation enthalten. Die Gewichtung und Bewertung erfolgt in Anlehnung an das in Abschnitt vorgestellte Vorgehen.

Techniken

201

Total Cost of Ownership

direkte Kosten

Hard- und Software

Systembetrieb

indirekte Kosten

Verwaltung

Endanwenderaktivitäten

Ausfallzeiten

Hardware für Anwenderbereich

technischer Support

Verwaltungs- und Finanzaufgaben

Futzing

geplante Ausfallzeiten

Software für Anwenderbereich

Planungs- / Prozessmanagement

Schulung der IT-Mitarbeiter

Selbsthilfe

ungeplante Ausfallzeiten

Hardware für IT-Abteilung

Datenbankmanagement

Schulung der Anwender

Fremdhilfe

Software für IT-Abteilung

Help Desk

Maßgrößen: Abschreibungen und Leasingkosten

Maßgrößen: Kosten durch Löhne und Gehälter sowie externe Dienstleistungen

Maßgrößen: Kosten durch Produktivitätsverluste oder entgangener Umsatz

Datenverwaltung

Anpassung von Software Schulungsmaßnahmen Maßgrößen: Kosten durch Produktivitätsverluste

Abb. 4.4.5.2/2: Kostenkategorien und Messgrößen des TCO-Ansatzes560

Grundsätzlich sind die Kostenkategorien in direkte und indirekte Kosten unterteilt.561 Die direkten Kosten umfassen dabei die Kategorien Hard- und Software, Systembetrieb sowie Verwaltung. Hinsichtlich der Hard- und Software sind dies zunächst sämtliche Kosten, die durch die Beschaffung der Integrationslösung anfallen. Dabei sind zum einen die dabei entstanden Kosten im Anwendungsbereich sowie zum anderen in der IT-Abteilung – im Sinne von Folgekosten etwa für eine Systemsoftware zur Fernwartung – zu ermitteln. Die Bestimmung der periodenspezifischen Kostenanteile erfolgt hierbei über die entsprechenden Abschreibungen bzw. Leasingraten. Im operativen Bereich sind ferner die Kosten erfasst, die sich aufgrund von Leistungen der IT-Mitarbeiter oder externen Dienstleistern für den Einsatz der Integrationslösung ergeben. Hinsichtlich der Kategorie Verwaltung sind die Kosten zu bestimmen, die sich aus der Organisation der IT-Abeitlungen der Netzwerkpartner bzw. einer übergeordneten IT-Abteilung ergeben. Im Hinblick auf die indirekten Kosten wird gemäß des TCO-Ansatzes zwischen Kosten aufgrund der Nutzung der Integrationslösung durch den Endanwender sowie Kosten aufgrund von Ausfallzeiten unterschieden. Die Kosten aufgrund von Aktivitäten des Endanwenders ergeben sich, wenn die Nutzer der Integration ihre eigentliche Kernaufgabe vernachlässigen und somit Produktivitätsverluste auftreten. Zusätzlich 560 561

In Anlehnung an Grob et al. (2004), S. 500. Im Detail siehe Wild/Herges (2000), S. 15. Vgl. hierzu und im Folgenden Pietsch (2003), S. 148-151; Grob et al. (2004), S. 499-502.

202

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

ergeben sich Produktivitätsverluste durch Ausfallzeiten des Systems, die ebenfalls zu Umsatzverlusten führen können. Im letzten Teilschritt sind den ausgewählten Kostenkategorien monetäre Größen zuzuordnen. Die Ermittlung der direkten Kosten kann dabei in Form von Preisübersichten, Tariftabellen für Angestellte oder über einzuholende Angebote erfolgen. Stellt somit die Ermittlung der direkten Kosten meist keine wesentliche Herausforderung dar, zeigen sich jedoch Schwierigkeiten bei der Ermittlung der indirekten Kosten, da sich etwa zu erwartenden Produktivitätsverluste bzw. Umsatzeinbußen nur schwer schätzen lassen. Die konkrete Erfassung der indirekten Kosten erfolgt in Form von Interviews und Umfragen der Endanwender und betroffenen IT-Abteilungen, die zur Ermittlung der Produktivitätsverluste noch mit den Lohn- und Gehaltskosten der Endanwender zu gewichten sind.562 Ergeben sich unterschiedliche Einschätzungen der Kosten zwischen den Netzwerkpartnern, so lassen sich diese durch deren Erörterung bzw. Korrektur sowie durch die Bildung von Durchschnittswerten zu einer einheitlichen Kostenübersicht für das vollständige Netzwerk zusammenfassen. Abgeschlossen ist der erste Schritt des Integrations-Assessments, sofern die Netzwerkpartner eine übergreifende Kostenübersicht erfasst und diese verabschiedet haben.

Schritt 2: Ermittlung des Integrationsnutzens Wie beschrieben lehnt sich die Erfassung des Integrationsnutzens grundsätzlich an den Ansatz der Nutzenanalyse an.563 Das Vorgehen zur Ermittlung des Integrationsnutzens gliedert sich mit der Identifizierung der Nutzeneffekte und ihrer Systematisierung sowie der Nutzenerhebung in zwei Teilschritte. Den Ausgangspunkt der Auswahl relevanter Kategorien des Integrationsnutzens bildet die bereits im Rahmen der Evaluation des Integrationsbereichs durchgeführte Nutzenbewertung einer integrierten Lösung.564 Zu überprüfen ist vom Netzwerk dabei zunächst, inwiefern die im Rahmen der Evaluation des Integrationsbereichs herangezogenen Nutzeneffekte für die Nutzenermittlung des Integrations-Assessment anzupassen sind. Im Anschluss an die Identifizierung relevanter Nutzeneffekte erfolgt deren Systematisierung in die Kategorien der Nutzenanalyse. Unterschieden wird dabei zwischen direktem, relativem und schwer fassbarem Nutzen, der sich aus dem Einsatz einer 562

563 564

Vgl. Wild/Herges (2000), S. 13. Zur Ermittlung der Umsatzeinbußen ist die Gewichtung hingegen nicht erforderlich. Diese wird lediglich durch Schätzungen, die auf den Interviews und Umfragen basieren, ermittelt. Vgl. Kapitel 4.4.5.1. Für eine Übersicht über den Ansatz vgl. Nagel (1990), S. 71-87. Vgl. Kapitel 4.4.3.2.

Techniken

203

Integrationslösung ergibt. Direkte Nutzeffekte sind alle Kosteneinsparungen, die unmittelbar der Implementierung einer integrierten Lösung folgen. Entsprechend sind die Nutzeffekte der Kostenkategorie typischerweise als „direkter Nutzen“ zu behandeln.565 Zukunftsgerichtete Einsparungen, die sich nicht unmittelbar aus dem Einsatz der Lösung ableiten, werden hingegen als „relativer Nutzen“ der Integrationslösung erfasst. Insbesondere die Effekte der Nutzenkategorien Zeit und Qualität lassen sich dem relativen Nutzen zuordnen. Schließlich werden sämtliche weiteren Effekte als „schwer fassbarer Nutzen“ behandelt. Typischerweise zählen die Nutzeffekte der Kategorie Strategie entsprechend zum schwer fassbaren Nutzen. Im zweiten Teilschritt der Nutzenerfassung erfolgt die Bestimmung des Nutzens einer integrierten Lösung durch die Netzwerkpartner. Dabei werden die Nutzeffekte für jeden Netzwerkpartner individuell erfasst und der entsprechenden Periode, in der sie anfallen zugeordnet. Die Erfassung des Nutzens erfolgt so weit wie möglich in Form von monetären Größen. Zur Ermittlung des direkten Nutzens sind dazu unmittelbar die erwarteten Kosteneinsparungen durch den Einsatz der integrierten Lösung zu schätzen.566 Grundlage hierfür bilden die Annahmen der Netzwerkpartner über das zukünftige Nutzenverhalten der integrierten Lösung, auf deren Basis die Nutzeffekte zu schätzen sind.567 Dieses lässt sich etwa in Form der erwarteten Transaktionen innerhalb einer Periode angeben. Für den relativen Nutzen sind darüber hinaus geeignete Bezugsgrößen wie etwa Stundenlöhne oder Stückpreise zu identifizieren, um auch für diese Kategorie monetäre Größen zu erhalten. Gelingt dies insbesondere bei den Nutzeffekten des schwer fassbaren Nutzens nicht, so sind die ermittelten Effekte in der Nutzenaufstellung jedoch als spätere Argumentationshilfe unbedingt ohne monetäre Größen darzustellen. Die individuellen Nutzenerfassungen der einzelnen Partner werden schließlich zu einem Gesamtnutzen summiert, der sich für das Netzwerk aus dem Einsatz der integrierten Lösung ergibt (vgl. Abb. 4.4.5.2/3).

565 566 567

Vgl. zu den Kategorien nochmals Abbildung 4.4.3.2/10. Vgl. hierzu und im Folgenden Emmelhainz (1990), S. 174-177. Vgl. Emmelhainz (1990), S. 176.

204

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Gesamtnutzen Partner n Partner 2 direkter Partner 1 Nutzeffekte Nutzen direkter Nutzeffekte Nutzen relativer direkter NutzNutzNutzen effekte effekte Nutzen relativer NutzNutzen effekte schwer relativer NutzNutzfassbarer Nutzen effekte effekte schwer Nutzen Nutzfassbarer effekte schwer Nutzen Nutzfassbarer effekte Nutzen

Perioden 1

2Perioden ... 1

2Perioden ... 1

2

Perioden 1

...

2

...

n

n n

direkter Nutzen

Nutzeffekte

relativer Nutzen

Nutzeffekte

schwer fassbarer Nutzen

Nutzeffekte

n

Summe

Summe

Summe Gesamtsumme

Abb. 4.4.5.2/3: Ermittlung des Gesamtnutzens aus den individuellen Nutzenerfassungen

Schritt 3: Investitionsauswahl Der dritte Schritt der vorliegenden Technik dient der Auswahl der Integrationslösung, die sich aus wirtschaftlichen Gesichtspunkten im Vergleich zu den anderen Lösungen als vorteilhaft zeigt. Die Grundlage des Vorgehens bildet die Kapitalwertmethode, bei der allgemein alle zukünftigen Ein- und Auszahlungen auf den Zeitpunkt unmittelbar vor der Investition abgezinst werden.568 Vorbereitend erfolgt in einem ersten Teilschritt zunächst die Bestimmung des Kalkulationszinssatzes in Abhängigkeit von den gewogenen Kapitalkosten sowie dem Investitionsrisiko. Daraufhin wird in einem zweiten Teilschritt durch die Gegenüberstellung der ermittelten Integrationskostenund -nutzeffekte die Auswahl der zu realisierenden Integrationslösung vorgenommen. Wie beschrieben erfolgt die Gegenüberstellung der Kosten- und Nutzeneffekte durch den Einsatz der Integrationslösung unter Zuhilfenahme der Kapitalwertmethode, die sich insbesondere aufgrund ihrer Einfachheit und Verbreitung in der Praxis für den Einsatz in Netzwerken eignet. Für die Kapitalwertberechnung ist zunächst der Kalkulationszinssatz zu bestimmen. Dabei lässt seine Anpassung die Berücksichtigung des Investitionsrisikos zu. Hintergrund ist die Möglichkeit, Projektrisiken durch die Veränderung des Kalkulationszinssatzes effizient in die Berechnung aufzunehmen, wobei die Wahl eines höheren Zinssatzes ein größeres Risiko aus Sicht der Investoren darstellt.569 Entsprechend besteht der Kalkulationszinssatz zur Beurteilung der Vorteilhaftigkeit der Integrationslösung aus zwei Komponenten. So beinhaltet er zum einen – wie grundsätzlich bei der Kapitalwertmethode – die gewogenen Kapitalkosten sowie zum anderen eine zusätzliche Risikoprämie. 568

569

Vgl. zur Bedeutung der Kapitalwertmethode für die Beurteilung von IT-Investitionen Tallon et al. (2002), S. 137; Nagel (1990), S. 66-68. Siehe auch Hirnle/Hess (2004), S. 90-91. Kritisch siehe Taudes et al. (2000), S. 228. Vgl. Perridon/Steiner (2004), S. 102.

Techniken

205

Die Höhe der gewogenen Kapitalkosten sollte so gewählt werden, dass sie der geforderten Mindestverzinsung des Netzwerks bzw. der daran beteiligten Netzwerkpartnern entspricht.570 Erhalten wird sie etwa anhand des gewogenen durchschnittlichen Zinssatzes der Fremd- und Eigenkapitalgeber des Netzwerks. Die Ermittlung erfolgt entsprechend anhand der Kapitalkosten für das Fremdkapital des Netzwerks, den kalkulatorischen Eigenkapitalkosten sowie dem Verhältnis zwischen Fremd- und Eigenkapital.571 Zur Berücksichtigung der Risiken ist der ermittelte Kalkulationszinssatz in einem weiteren Schritt anzupassen. Dabei erfolgt die Anpassung zum einem aufgrund netzwerkspezifischer Risiken sowie zum anderen aufgrund allgemeiner Prognoseunsicherheit über die zu erwartenden Investitionsrückflüsse. Erfolgen kann sie in Anlehnung an die bereits im Rahmen der Technik „Evaluation der Integrationsbereiche“ durchgeführte Risikobeurteilung.572 Dabei ist das Risiko einer Integrationslösung anhand gewichteter Aspekte zur Risikoeinschätzung von den Netzwerkpartnern zu ermitteln und die Integrationslösung in Lösungen mit hohem oder geringem Risiko zu klassifizieren. Darüber hinaus sind die Integrationslösungen hinsichtlich zweier netzwerkspezifischen Risiken zu beurteilen, die ebenfalls den Kalkulationszinssatz beeinflussen können. Dabei sind die jeweiligen Integrationslösungen zum einen hinsichtlich ihrer Spezifität von den Netzwerkpartnern zu beurteilen. Netzwerkspezifische Investitionen lassen sich lediglich innerhalb des Netzwerks nutzen und haben für die Partnerunternehmen außerhalb des Netzwerks keinen Wert. Entsprechend bergen Investitionen ein höheres Risiko je spezifischer sie für das Netzwerk sind. Darüber hinaus sind die partnerbezogenen Risiken durch die Netzwerkpartnern zu ermitteln. Hintergrund der partnerbezogenen Risiken bilden fehlende Informationen über das finanzielle und technische Leistungsvermögen der Partnerunternehmen sowie über deren Bereitschaft, die Investition im Sinne der getroffenen Vereinbarungen durchzuführen.573 Ausgehend von den jeweiligen Einzeleinschätzungen der Netzwerkpartner werden die untersuchten Integrationslösungen in eine Matrix mit den Dimensionen „Netzwerkspezifität der Integrationslösung“ sowie „partnerbezogene Unsicherheit“ eingeordnet. Als dritte Dimension wird zusätzlich die zuvor ermittelte „Prognoseunsicherheit über die zu erwartenden Investitionsrückflüsse“ durch die Größe der Kreise innerhalb der Matrix festgehalten, wobei kleine Kreise für ein geringe Prognoseunsi-

570 571 572 573

Vgl. Hirnle/Hess (2004), S. 90. Vgl. Perridon/Steiner (2004), S. 87. Vgl. Kapitel 4.4.3.2. Vgl. Das/Teng (1996), S. 831.

206

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

cherheit und große Kreise für eine hohe Prognoseunsicherheit stehen (vgl. Abb. 4.4.5.2/4). hohes netzwerkspezifisches Risiko

partnerbezogene Unsicherheit

IL2 g IL1

mittleres netzwerkspezifisches Risiko geringes netzwerkspezifisches Risiko

= geringe Prognoseunischerheit

h IL3 g

= hohe Prognoseunischerheit

h

Netzwerkspezifität der Integrationslösung

IL= Integrationslösung

Abb. 4.4.5.2/4: Portfolio zur Erfassung der Investitionsrisiken

Je nach Einordnung der infrage kommenden Integrationslösungen in das Portfolio und der Größe des Kreises erfolgt die Adjustierung des Kalkulationszinssatzes. Bei geringem netzwerkspezifischen Risiko bzw. geringer Prognoseunsicherheit muss keine Anpassung erfolgen. Hingegen ist bei mittlerem und hohem netzwerkspezifischen Risiko bzw. hoher Prognoseunsicherheit ein Aufschlag auf den Kalkulationszinssatz vorzunehmen. Im Anschluss an die Anpassung des Kalkulationszinssatzes ist jeweils der Kapitalwert der infrage kommenden Integrationslösungen zu bestimmen. Dies erfolgt unter Berücksichtigung der jeweiligen Zahlungsreihen der Integrationskosten aus dem ersten Schritt sowie dem Gesamtnutzen der Integrationslösung aus dem zweiten Schritt und der jeweils angepassten Kalkulationszinssätze aus dem dritten Schritt sowie der Formel zur Kapitalwertberechnung (vgl. Abb. 4.4.5.2/5).

C0

n

Et  At ˜ 1 t ¦ 1  i t 0

C0 t Et At i

= Kapitalwert = einzelne Perioden von 0 bis n = Gesamtnutzen der Periode t = Integrationskoten der Periode t = Angepasster Kalkulationszinssatz

Abb. 4.4.5.2/5: Formel zur Kapitalwertberechnung574

Nach der Berechnung der jeweiligen Kapitalwerte für die infrage kommenden Integrationslösungen sind für die Auswahl einer Investitionsalternative zusätzlich die qualitativen Argumente der Integrationslösung hinzuzuziehen. Dies erfolgt durch die Aufstellung einer Argumentenbilanz, bei der die nicht monetär erfassbaren Kosteneffekte den qualitativen Nutzeneffekten der Integrationslösung gegenübergestellt wer-

574

Vgl. Perridon/Steiner (2004), S. 61.

Techniken

207

den.575 Aus den Investitionsalternativen wählt das Netzwerk schließlich in Abhängigkeit vom entsprechenden Kapitalwert und der zugrunde liegenden Argumentenbilanz eine zu realisierende Integrationslösung aus und verabschiedet offiziell deren Umsetzung. Findet sich keine vorteilhafte Integrationslösung, so ist vom Netzwerk über das weitere Vorgehen zu entscheiden, etwa in Form des Projektabbruchs oder der Validierung der Parameter der Wirtschaftlichkeitsbeurteilung.

Schritt 4: Investitionskostenverrechnung Aufgrund der innerhalb von Netzwerken bestehenden Opportunismusgefahr hinsichtlich der Angabe über die Kosten und den Nutzen einer Integrationslösung könnte im Extremfall die Realisierung einer grundsätzlich vorteilhaften Integrationslösung unterlassen werden.576 Dieses Problem lässt sich allerdings durch die vom tatsächlichen Nutzenverhalten abhängige Verrechnung der Investitionskosten vermindern. Den Hintergrund der Verrechnung der Investitionskosten bildet dabei sowohl das ex-ante prognostizierte als auch das ex-post gemessene Nutzungsverhalten der Integrationslösung durch die jeweiligen Netzwerkpartner. Dabei soll der Einbezug des ex-post gemessenen Nutzungsverhaltens die ex-ante Untertreibung des Nutzens durch die Netzwerkpartnern eindämmen. Für die Verrechnung der Integrationskosten bieten sich unterschiedliche Prinzipien der Kostenverteilung an. Unter den Prinzipien der Kostenverteilung ist das Verursachungsprinzip besonders verbreitet.577 Bei der Verteilung der Kosten von Integrationsprojekten eignet sich als Maßstab einer verursachungsgerechten Verteilung grundsätzlich die Systemnutzung der Partnerunternehmen. Vom Netzwerk ist allerdings in einem ersten Teilschritt zu entscheiden, ob eine Verrechnung der Investitionskosten nach dem Verursachungsprinzip und damit nach dem Nutzungsverhalten der Partnerunternehmen sinnvoll ist. Typischerweise ist dies der Fall für Integrationslösungen der auftragsbezogenen Ebene des Netzwerks. So ist zu erwarten, dass ein Netzwerkpartner, der eine Integrationslösung der auftragsbezogenen Ebene verwendet, direkt an den sich daraus ergebenden Nutzeffekten partizipiert, die im zweiten Schritt der vorliegenden Technik ermittelt wurden. Entsprechend ergeben sich für einen Partner keine Nutzeffekte aus der Integrationslösung, sofern er nicht am jeweiligen Auftrag beteiligt ist.

575 576 577

Vgl. Potthof (1998), S. 18. Vgl. zum Opportunismusrisiko Kapitel 4.4.5.1 bzw. Hirnle (2006), S. 38. Zum Verursachungsprinzip als verbreitetes Verfahren der Kostenverrechnung vgl. Schweitzer/Küpper (2003), S. 54-55. Für den Einsatz des Prinzips bei der Kostenverteilung für die Nutzung von Anwendungssystemen vgl. Heinrich (2002), S. 506.

208

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Hingegen sind die Nutzeffekte im Rahmen der Nutzung einer Integrationslösung zur Unterstützung der auftragsübergreifenden Ebene typischerweise nicht auf den Netzwerkpartner beschränkt, der tatsächlich das integrierte System einsetzt. Vielmehr partizipiert ein Großteil der Partnerunternehmen des Netzwerks vom Einsatz der Integrationslösung auf auftragsübergreifender Ebene. Dies ist etwa der Fall, sofern nur eines bzw. wenige Unternehmen die Aufgaben der auftragsübergreifende Ebene übernehmen. Folglich wären diese Netzwerkpartner auch die wesentlichen Nutzer der Integrationslösung, unabhängig davon, ob sie an den damit verbundenen Nutzeffekten partizipieren. Ist vom Netzwerk die Entscheidung über die Eignung des Verursachungsprinzips zur Kostenverteilung getroffen worden, so sind die anfallenden Kosten für die Integrationslösung anhand des jeweils prognostizierten Nutzens der Netzwerkpartner aus dem zweiten Schritt der vorliegenden Technik zu verteilen. Endet die Verrechnung der Investitionskosten an dieser Stelle, so besteht die Gefahr, dass die Netzwerkpartner ihren Nutzen im Rahmen der Nutzenerfassung untertreiben, um mit einem geringeren Kostensatz an der Investition beteiligt zu werden. Um dies zu verhindern ist im Anschluss an die Realisierung eine Nachberechung vorzunehmen, die sich nicht an der erwarteten, sondern an der tatsächlichen Systemnutzung durch die Netzwerkpartner orientiert. Dafür ist zu erfassen, inwiefern das im zweiten Schritt angegebene Nutzungsverhalten mit dem tatsächlichen Nutzungsverhalten übereinstimmt. Die Messung des tatsächlichen Nutzungsverhaltens kann etwa anhand der abgewickelten Transaktionen, der beanspruchten Login-Zeiten oder der übertragenen Datenmenge erfolgen.578 Mittels der erhaltenen Größen lassen sich schließlich Rückschlüsse auf die tatsächlichen Nutzeffekte der Netzwerkpartner ziehen. Je nachdem wie genau die im zweiten Schritt der Technik erfolgte Schätzung der Nutzung der integrierten Lösung durch die Netzwerkpartner war, kommt es im Rahmen der Nachberechnung zu Nachbelastungen bzw. Rückerstattungen (Sidepayments) der Kosten.579 Entsprechend wird die Untertreibung des Nutzungsverhaltens sanktioniert, da die Netzwerkpartner in den folgenden Perioden und in Abhängigkeit zum tatsächlichen Nutzungsverhalten eine Nachzahlung leisten müssen. Abschließend ist bei der Nachberechnung von den beteiligten Netzwerkpartnern festzulegen, inwiefern die Nachberechnung in der Folgeperiode ein weiteres Mal durchgeführt werden soll. Dies ist nicht der Fall, wenn die Kostenverteilung von sämtlichen Netzwerkpartnern als gerecht empfunden wird.

578

579

Diese und weitere Bezugsgrößen zur Messung der tatsächlich Systemnutzung finden sich etwa bei Heinrich (2002), S. 506. Zu Sidepayments im Rahmen kollektiver Investitionen vgl. etwa Müller-Tengelmann (1994), S. 7071.

Ergebnismodell

209

Anders gestaltet sich allerdings die Verrechnung der Integrationskosten, sofern das Netzwerk – wie dies typischerweise bei der Integrationslösung auf auftragsübergreifender Ebene der Fall ist – eine verursachungsgerechte Kostenverteilung ablehnt. In diesen Fällen bietet sich die Verrechnung der Investitionskosten anhand des Durchschnitts oder Tragfähigkeitsprinzips an.580 Allgemein werden die anfallenden Integrationskosten bei ersterem anhand der Anzahl der Partnerunternehmen oder sonstigen Bezugsgrößen, wie Mengen- oder Wertgrößen verteilt. Dabei erfolgt die Verteilung der Investitionsgrößen proportional, wobei keine verursachungsgemäße Kostenverteilung angestrebt wird. Bei der Kostenverteilung gemäß dem Tragfähigkeitsprinzip wird der Investitionsanteil anhand der jeweiligen Belastbarkeit bzw. Leistungsfähigkeit auf die Netzwerkpartner verteilt, die sich etwa aus dem Umsatzanteil eines Netzwerkpartners am Gesamtnetzwerkumsatz einer definierten Periode ergibt. In Abhängigkeit vom gewählten Prinzip erfolgt schließlich die Bestimmung der jeweiligen Integrationskosten für die einzelnen Partnerunternehmen. Abgeschlossen wird die Technik entsprechend mit der Verabschiedung der von den Partnerunternehmen zu übernehmenden Investitionskosten. Mit diesem Schritt endet die Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken. 4.5

Ergebnismodell

Die Aktivitäten bzw. die damit verbundenen Techniken dienen der Erzeugung von Ergebnissen, die im Rahmen der beschrieben Methode typischerweise in Form von Dokumenten erhalten werden. Grundsätzlich zielt die Erarbeitung von Ergebnisdokumenten auf zwei Sachverhalte ab: Zum einen dienen die Ergebnisdokumente der Komplexitätsreduktion. Dies ist insbesondere nötig, sofern viele Akteure beteiligt sind – wie bei der Integration in Netzwerken allein durch die Anzahl der Partnerunternehmen eines Netzwerks regelmäßig zu erwarten –oder nicht alle Aktivitäten von einer einzigen Person durchzuführen sind.581 Die Zusammenfassung der erhaltenen Ergebnisse in Dokumenten ermöglicht für diese Fälle eine vereinfachte Kommunikation zwischen den Projektbeteiligten. Neben der Kommunikationsvereinfachung kommt den Ergebnisdokumenten eine weitere Aufgabe zu. So unterstützen Ergebnisdokumente vorheriger Aktivitäten der Methode die Validierung der in späteren Phasen erhaltenen Ergebnisse, d. h. die Ergebnisse lassen sich im Hinblick auf ihre Vereinbarkeit mit den zuvor verabschiedeten Ergebnissen auf ihre Richtigkeit (Validität) hin untersuchen.582

580 581 582

Vgl. hierzu und im Folgenden Schweitzer/Küpper (2003), S. 58. Vgl. Hess (1996), S. 137. Deutlich wird dieser Sachverhalt etwa bei der Betrachtung von Aufgaben einer Anwendungssystemspezifikation respektive Integrationsspezifikation. Diese liegt in der Zusammenfassung aller

210

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

Dieser Abschnitt beschränkt sich auf einen Überblick über die relevanten Ergebnisdokumente im Rahmen der vorgestellten Methode. Die ausführliche Darstellung der Dokumente erfolgte bereits im Rahmen der Beschreibung der Techniken.583 Die Vorstellung der Ergebnisdokumente in diesem Abschnitt zielt vielmehr auf die Herstellung der Beziehung zwischen den Komponenten des Metamodells und den Techniken der Methode. Dazu erfolgt ein Überblick über die relevanten Ergebnisdokumente jeweils für die einzelnen Techniken der Methode getrennt voneinander. Enthalten ist in der Übersicht neben der Beschreibung des jeweiligen Ergebnisdokuments folglich auch dessen korrespondierende Objektklasse aus dem Metamodell sowie der Hinweis, im Rahmen welcher Technik das Ergebnisdokument wieder verwendet wird. Die Ergebnisdokumente der Technik „Ermittlung der Netzwerkorganisation“ bilden den Ausgangspunkt der Methode. Sie dienen zum einen der strukturierten Erfassung der Netzwerkziele sowie der Ableitung und Darstellung der Netzwerkprozessorganisation. Die Ergebnisdokumente der ersten Technik decken fünf Komponenten des Metamodells ab. Diese sind das „Netzwerk“, dessen „Partner“ und „Ziele“ sowie die „Prozesse“ bzw. „Prozesskomponenten“ (vgl. Abb. 4.5/1). Ergebnisdokument

Beschreibung

MetamodellKomponenten

Input der Technik

Zielverabschiedung

Textuelle Übersicht über die verabschiedeten Netzwerkziele

Ziel, Netzwerk, Partner

• Ermittlung der Netzwerkorganisation • Evaluation der Integrationsbereiche

Prozessübersicht

Beschreibung der Prozesse inklusive Anfangsund Endpunkte, Prozessobjekte sowie In- und Outputs

Ziel, Prozess

• Ermittlung der Netzwerkorganisation

Netzwerk-ProzessOrganisationsDiagramm

Grafische Darstellung der Beziehungen zwischen Prozesskomponenten und Aufbauorganisation

Prozess, Prozesskomponente, Partner

• Identifikation der Integrationsbereiche

Abb. 4.5/1: Ergebnisdokumente zur Ermittlung der Netzwerkorganisation

Gemäß den beiden Varianten der für die Integration in Unternehmensnetzwerken relevanten Integrationsbereiche kommen den Ergebnisdokumenten im Rahmen der Technik „Identifizierung der Integrationsbereiche“ zwei Aufgaben zu.584 Zum einen dienen die Anwendungssystemlandkarte sowie die Prozess-Systemmatrix der Identifizierung der Integrationsbereiche hinsichtlich Prozessen, die bisher nicht bzw. kaum durch den Einsatz von Anwendungssystemen unterstützt werden. Da die Aufdeckung

583 584

fachlichen Anforderungen an das gewünschte System und dient einem Auftragnehmer als Vorlage für die zu entwickelnde Lösung sowie einem Auftragnehmer zur Überprüfung, inwiefern die gelieferte Lösung den geforderten Anforderungen entspricht (vgl. etwa Balzert (2000), S. 113; Schnupp/Floyd (1979), S. 152). Vgl. zu diesem Vorgehen etwa Legner (1999), S. 87; Muschter (1998), S. 9. Für die Varianten der Integrationsbereiche, die für die Integration in Netzwerken zu berücksichtigen sind vgl. Kapitel 4.4.2.1.

Ergebnismodell

211

dieser Integrationsbereiche noch weitgehend ohne die Betrachtung der Informationsflüsse innerhalb und zwischen den Prozessen erfolgten, findet sich als korrespondierende Komponenten des Metamodells lediglich der „Prozesse“ sowie die dafür eingesetzte „Anwendungssysteme“ und die „Netzwerkpartner“, die diese Anwendungssysteme nutzen. Ebenfalls sind für das Netzwerk jedoch Integrationsbereiche für Prozesse zu finden, die derzeit intensiv durch Anwendungssysteme unterstützt werden. Dazu sind die Ergebnisdokumente zur Analyse der Kommunikationsbeziehungen von Bedeutung. Untersucht wird mit ihrer Hilfe der Verlauf der Informationsobjekte, die zwischen den Prozesskomponenten ausgetauscht werden sowie die Anwendungssysteme, die zur Verarbeitung der Informationsobjekte bei den Netzwerkpartnern aufzufinden sind. Entsprechend sind neben Prozess, Partner und Anwendungssystem hinsichtlich der korrespondierenden Komponenten des Metamodells ebenfalls die Prozesskomponenten „Kommunikationsbeziehung“ sowie „Informationsobjekt“ zu berücksichtigen. Zusammenfassend finden sich die Ergebnisse der beiden Varianten zur Identifikation der Integrationsbereiche in Unternehmensnetzwerken schließlich im Ergebnisdokument zur Definition der Integrationsbereiche (vgl. Abb. 4.5/2). Ergebnisdokument

Beschreibung

MetamodellKomponenten

Input der Technik

Anwendungssystemlandkarte

Übersicht über die einen Prozess unterstützenden Anwendungssysteme

Prozess, Anwendungssystem

• Identifikation der Integrationsbereiche

System-ProzessMatrix

Zeigt Prozesse mit lückenhafter Anwendungssystemunterstützung auf

Prozess, Partner Anwendungssystem

• Identifikation der Integrationsbereiche • Integrationsspezifikation

Übersicht der Kommunikationsbeziehungen

Stellt grafisch den Zusammenhang des Informationsflusses im Netzwerk dar

Prozess, Prozesskomponente, Informationsobjekte

• Identifikation der Integrationsbereiche

Detailanalyse der Kommunikationsbeziehungen

Schematische Analyse der Kommunikationsbeziehungen zwischen den Anwendungssystemen

Partner, Prozesskomponente, Kommunikationsbeziehung, Anwendungssystem

• Identifikation der Integrationsbereiche • Integrationsspezifikation

Definition der Integrationsbereiche

Textuelle Beschreibung der identifizierten Integrationsbereiche

Integrationsbereich, Prozess, Prozesskomponente, Anwendungssystem

• Integrationsevaluation

Abb. 4.5/2: Ergebnisdokumente zur Identifikation der Integrationsbereiche

Die Ergebnisdokumente der Technik zur Evaluation der Integrationsbereiche dienen der Einschätzung der Integrationsbedeutung und -attraktivität. Erstere analysiert den Integrationsbereich im Hinblick auf den Integrationsbedarf sowie die Zielunterstützung des Integrationsbereichs durch dessen Beitrag zu den kritischen Erfolgsfaktoren des Unternehmensnetzwerks. Letztere hingegen analysiert den Nutzen und die Risiken der Realisierung. Korrespondierende Komponenten des Metamodells der Methode sind entsprechend die „Ziele“ und die „kritischen Erfolgsfaktoren“ des Netz-

212

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

werks, neben dem „Integrationsbereich“ und der damit verbundenen „Integrationsbedeutung“ sowie „-attraktivität“ (vgl. Abb. 4.5/3). Ergebnisdokument

Beschreibung

MetamodellKomponenten

Input der Technik • Integrationsevaluation

Kritische Erfolgsfaktoren

Verzeichnis der kritischen Erfolgsfaktoren des Netzwerks

Ziele, kritische Erfolgsfaktoren, Integrationsbereich

Gesamtportfolio der evaluierten Integrationsbereiche

Visualisierung der Evaluation der Integrationsbereiche anhand der Integrationsattraktivität und -bedeutung

Integrationsbereich, Integrationsattraktivität / -bedeutung

• Integrationsevaluation

Erweiterte Definition der Integrationsbereiche

Erweiterte Beschreibung eines Integrationsbereichs um die Integrationsattraktivität und -bedeutung

Integrationsbereich, Integrationsattraktivität / -bedeutung

• Integrationsspezifikation

Abb. 4.5/3: Ergebnisdokumente zur Evaluation der Integrationsbereiche

Im Kern umfasst die Integrationsspezifikation drei Ergebnisdokumente, die der Ermittlung sämtlicher Anforderungen an die Integrationslösung dienen. Ausgangspunkt dafür ist die Integrationsvision, die als Grundlage für die Integrationsspezifikation dient. Eine korrespondierende Komponente des Metamodells ist neben dem „Integrationsbereich“ für den die Vision aufzustellen ist, entsprechend auch die angestrebte „Integrationsarchitektur“. Beteiligt an der Anforderungsermittlung sind ausgehend von der Integrationsvision schließlich die Viewpoints, die vom Integrationsbereich betroffen sind. Die vom Netzwerk ausgewählten und vorwiegend zu den Partnern gehörenden Viewpoints sind in der Viewpointübersicht enthalten. Entsprechend sind „Netzwerk“, „Partnerunternehmen“, „Integrationsbereich“ sowie „Viewpoint“ die korrespondierenden Komponenten dieses Ergebnisdokuments mit dem Metamodell der Methode. Schließlich bildet die Anforderungsspezifikation der Integrationslösung, in der die ermittelten Anforderungen enthalten sind, das finale Ergebnisdokument der Integrationsspezifikation. Korrespondierende Komponenten des Metamodells sind hierbei der „Integrationsbereich“, die „Integrationslösung“, die „Anforderung“ sowie die „Anforderungsspezifikation“ (vgl. Abb. 4.5/4). Ergebnisdokument

Beschreibung

MetamodellKomponenten

Input der Technik

Integrationsvision

Beschreibung der Vision der angestrebten Integrationslösung

Integrationsbereich, Integrationsarchitektur

Viewpointübersicht

Verzeichnis der ermittelten Viewpoints zur Anforderungsermittlung

Partner, Viewpoint, Integrationsbereich

• Integrationsspezifikation

Anforderungsspezifikation

Detaillierte Beschreibung der Integrationslösung

Integrationsbereich, Integrationslösung, Anforderung, Anforderungsspezifikation

• IntegrationsAssessment

• Integrationsspezifikation

Abb. 4.5/4: Ergebnisdokumente zur Integrationsspezifikation

Rollenmodell

213

Die Ergebnisdokumente des Integrations-Assessments dienen der Erfassung der Kosten und des Nutzens, die mit einer Integrationslösung verbunden sind. Diese bilden die Grundlage für die Auswahl einer geeigneten Investitionsalternative durch das Netzwerk. Korrespondierende Komponenten des Metamodells sind entsprechend die „Integrationslösung“, die „Kosten“ und der „Nutzen“ sowie die „Netzwerkpartner“, da diese die Kosten übernehmen bzw. vom Nutzen der Integrationslösung profitieren (vgl. Abb. 4.5/5).

Beschreibung

MetamodellKomponenten

Kostenaufstellung

Detaillierte Beschreibung sämtlicher Kosten der Integrationslösung

Integrationslösung, Kosten

• IntegrationsAssessment

Nutzenaufstellung

Detaillierte Beschreibung sämtlicher, bewertbarer Nutzeneffekte der Integrationslösung

Integrationslösung, Nutzen, Partner

• IntegrationsAssessment

Investitionsalternativenvergleich

Überblick über die möglichen Investitionsalternativen des Netzwerks

Integrationslösung, Kosten, Nutzen

• IntegrationsAssessment

Verabschiedete Investitionskosten auf Partnerebene

Erfassung der verabschiedeten Investitionskosten, die von den jeweiligen Partnerunternehmen zu übernehmen sind

Partner, Kosten

weiteres Integrationsvorgehen

Ergebnisdokument

Input der Technik

Abb. 4.5/5: Ergebnisdokumente des Integrations-Assessments

4.6

Rollenmodell

Das vorliegende Kapitel gibt eine Übersicht über die organisatorische Ausgestaltung der Integrationsplanung und -bewertung in Unternehmensnetzwerken. Beleuchtet werden dabei zunächst die netzwerkspezifischen Besonderheiten von Integrationsprojekten. Im Anschluss daran werden die übernommenen Rollen der am Integrationsmanagement beteiligten Akteure vorgestellt. 4.6.1 Netzwerkspezifische Besonderheiten Für Netzwerke sind im Rahmen des Rollenmodells zwei Besonderheiten zu beachten: Zunächst gilt es zu berücksichtigen, dass die Integrationsplanung und -bewertung auf zwei Ebenen des Netzwerks erfolgt. Auf der partnerbezogenen Ebene befinden sich die bestehenden Anwendungssysteme der Netzwerkpartner, die zu identifizieren sind sowie die bestehenden Schnittstellen und benötigten Daten zur Aufgabendurchführung. Entsprechend ist diese partnerbezogene Ebene im Rahmen der Integration ebenso wie eine partnerübergreifende Ebene zu berücksichtigen, auf der die Integrationsziele des Netzwerks sowie die Evaluation der Integrationsbereiche erfolgt. Wie beschrieben kennzeichnen sich Unternehmensnetzwerke jedoch durch eine weitgehende Funktionsabstimmung, aufgrund derer typischerweise innerhalb des Netz-

214

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

werks keine gemeinsamen Ressourcen bestehen.585 Demzufolge ist anzunehmen, dass die Integrationsplanung und -bewertung ebenfalls weitgehend im Rahmen der Funktionsabstimmung erfolgt. Für die Aktivitäten der Integrationsplanung und -bewertung auf partnerbezogener Ebene führt diese Überlegung noch keine besonderen Implikationen mit sich. Es ist lediglich davon auszugehen, dass die Akteure der jeweiligen Partnerunternehmen – aufgrund der fehlenden gemeinsamen Ressourcen – die relevanten Tätigkeiten der Integrationsplanung und -bewertung weitgehend selbst übernehmen. Anders gestaltet sich hingegen das Bild für Tätigkeiten auf der partnerübergreifenden Ebene. Aufgrund der Funktionsabstimmung müssen diese ebenfalls weitgehend von den Akteuren der jeweiligen Partnerunternehmen übernommen werden. Je nach konkreter Netzwerk- bzw. Projektausgestaltung werden sie dabei jedoch unter Umständen von einem eventuell eingesetzten Netzwerkkoordinator oder externen Integrationsexperten unterstützt, wie etwa in Form einer Unternehmensberatung. Demzufolge ist im Hinblick auf das Rollenmodell zu beachten, dass je nach Ausgestaltung des Projekts und Netzwerks ein Akteur unter Umständen unterschiedliche Rollen übernimmt (vgl. Abb. 4.6.1/1).

MA1 Integrationsleitung MA1

partnerübergreifende Ebene

partnerbezogene Ebene

MA2

MA n

Integrationskernteam

MA1

MA2

Führungsverantwortlicher

Fachbereichsvertreter

Partner 1

Partner 2

MA n

MA n

...

Fachbereichsvertreter Partner n

= Mitarbeiter des Netzwerkpartners n

Abb. 4.6.1/1: Projektbeteiligte mit mehreren Rollen im Rahmen des Integrationsvorgehens

Des Weiteren sind bei der Betrachtung des Rollenmodells die zwei vorgestellten Steuerungsformen von Unternehmensnetzwerken zu berücksichtigen.586 Unterschieden wurden dabei fokal und polyzentrisch gesteuerte Netzwerke. Die untersuchten Fallstudien zeigten, dass sich die bestehende Steuerungsform des Netzwerks auf die organisatorische Ausgestaltung des Integrationsvorgehens auswirkte. So lag bei den polyzentrisch gesteuerten Netzwerken eine vermehrt durch heterarchische Elemente

585 586

Vgl. Kapitel 2.1.1.2. Vgl. Kapitel 2.1.1.3.

Rollenmodell

215

geprägte Projektorganisation vor, wohingegen bei den fokal gesteuerten Netzwerken eine stark hierarchische geprägte Organisation des Integrationsvorgehens angetroffen wurde. Unterschiede der beiden Organisationsformen zeigen sich insbesondere bei den Akteuren, die über eine Entscheidungsbefugnis im Rahmen der Integrationsprojekte verfügen. Werden die Entscheidungen bei hierarchisch geprägten Projekten im Wesentlichen durch einen einzelnen Vertreter des fokalen Netzwerkpartners getroffen, so erfolgen Entscheidungen durch heterarchisch geprägte Elemente der Projektorganisation durch einen Ausschuss, besetzt mit weitgehend gleichberechtigten, entscheidungsbefugten Vertretern der jeweiligen Partnerunternehmen und unter Zuhilfenahme von Abstimmungsmechanismen (vgl. Abb. 4.6.1/2).587 Integrationsausschuss

Integrationsleiter FMA

FMA2

MA1

...

...

FMAn

MA1 P1

MA

n

MA2 P1

MA1 P2

MAn Pn

...

...

...

...

MA3

Partner 1

Partner 2

MAn P1 ...

Partner m

Partner 1

hierarchisch geprägte Projektorganisation FMA1 MA

n

MAn Pm

MA3 Pn MA2 P2

1

MAn P2 Partner 2

...

Partner m

durch heterarchische Elemente geprägte Projektorganisation

= Mitarbeiter / Bereich n des fokalen Netzwerkpartners = Mitarbeiter / Bereich n eines nicht-fokalen Netzwerkpartners = Mitarbeiter / Bereich n des nicht-fokalen Netzwerkpartners m

Abb. 4.6.1/2: Varianten der Organisation von Integrationsprojekten

4.6.2

Rollen innerhalb von Integrationsprojekten in Netzwerken

Im Rahmen der Projekte zur Integrationsplanung und -bewertung werden Rollen von Geschäftseinheiten, Mitarbeitern oder Netzwerkexternen übernommen. Rollen sind mit Aufgaben verbunden und setzen bestimmte Kompetenzen sowie Befugnisse voraus. Anhand der Rollen lassen sich im Rahmen der Methodenanwendung den Akteure den konkreten Aktivitäten zuordnen.588 Wie bereits bei den Besonderheiten der Organisation von Integrationsprojekten in Netzwerken beschrieben, sind zwei integrationsrelevante Ebenen zu berücksichtigen. Die erste Ebene bezieht sich auf sämtliche Aktivitäten, die bei der Durchführung 587 588

Vgl. auch Wohlgemuth (2002), S. 118-120. Vgl. Kremer (2004), S. 121.

216

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

der Integrationsmethode Partnerunternehmen-übergreifend im Netzwerk anfallen. Ein typisches Beispiel für eine solche Aktivität ist etwa die Definition der Netzwerkziele oder das Integrations-Assessment. Neben der Partnerunternehmenübergreifenden Ebene findet sich im Rahmen von Integrationsprojekten eine Partnerunternehmen-bezogene Ebene. Auf dieser fallen die Aktivitäten an, die nicht das Netzwerk, sondern lediglich die jeweils von einem Integrationsprojekt betroffenen Partnerunternehmen berühren. Typische Aktivitäten auf dieser Ebene finden sich in Form der Erfassung der vorhandenen Anwendungssysteme zur Unterstützung eines Integrationsbereichs oder bei der Analyse der Ist-Situation. Entsprechend ist das Rollenmodell für die Methode zur die Integrationsplanung und -bewertung an die beiden Ebenen anzupassen. Daher finden sich im Folgenden zwei Teilrollenmodelle, die sich jeweils auf die entsprechende Ebene beziehen. Die Teilrollenmodelle sind zunächst anhand der bekannten Rollen der involvierten Mitarbeiter systematisiert.589 Diese umfassen auf der untersten Ebene die Rollen (1) des Unterstützers sowie auf der nächst höheren Ebene (2) den Verantwortlichen und schließlich auf höchster Ebene (3) den Entscheider. Kennzeichen des Unterstützers ist sein inhaltliches Wissen, welches er im Sinne eines Informationslieferanten in das Projekt einbringen kann, sowie seinen Beitrag an operativen Tätigkeiten im Rahmen der Projektarbeit. Hingegen ist der Verantwortliche auf nächst höherer Stufe als zuständige Person für das termingerechte Erreichen und Weiterleiten von Ergebnissen sowie für operative Tätigkeiten im Rahmen der Projekttätigkeiten auf einem aggregierten Niveau zu charakterisieren. Auf höchster Stufe der Systematisierung ist schließlich der Entscheider als ein mit Entscheidungsbefugnissen ausgestatteter Akteur angesiedelt. Die Systematisierung der beiden Teilrollenmodelle mit den skizzierten allgemeinen Rollen führt zu sechs relevanten Rollen, die im Rahmen von Integrationsprojekten in Unternehmensnetzwerken zu berücksichtigen sind (vgl. Abb. 4.6.2/1).

589

Vgl. hierzu und im Folgenden etwa Alt et al. (2004), S. 265; Puschmann (2003), S. 15-16. Ähnlich Gorla/Lam (2004), S. 80; Stietz (1995), S. 210-212.

Rollenmodell

Partnerunternehmenbezogene Integrationsorganisation

Partnerunternehmenübergreifende Integrationsorganisation

Teilrollenmodell

217

Stufe

Rolle

Kernaufgaben

mögliche Besetzung

Entscheider

Integrationsleitung

Leitung und Koordination des Gesamtprojekts

Führungsverantwortlicher

Veranwortlicher

Integrationskernteam

Identifizierung, Evaluation und Assesment der IBs

Fachbereichsleiter

Unterstützung

Int. / Ext. Integrationsexperte

Unterstützung des Integrationskernteams

Unternehmensberatung mit ITSchwerpunkt

Entscheider

Leitung der Partnerunternehmen

Beteiligt an Zieldefinition und Entscheidung über Beteiligung am Integrationsprojekt

Führungsverantwortlicher

Verantwortlicher

Integrationsverantwortlicher der Partnerunternehmen

Partnerunternehmen-interne Integrationsprojektkoordination

Fach- oder ITBereichsleiter

Unterstützung

Beteiligter am Integrationsbereich

Unterstützung der Identifizierung der IBs und Teilnahme an der Integrationsspezifikation

Fachbereichsmitarbeiter

Abb. 4.6.2/1: Rollenmodell für Integrationsplanung und -bewertung in Netzwerken

Entscheider im Rahmen der Partnerunternehmen-übergreifenden Integrationsorganisation ist die Integrationsleitung. Diese ist allgemein für die übergeordnete Steuerung des Integrationsprojektes verantwortlich.590 Entsprechend hat sie die Richtung des Integrationsprojekts vorzugeben sowie dieses zu beaufsichtigen.591 Ebenfalls obliegt der Integrationsleitung die letztendliche Entscheidung über den tatsächlich zu realisierenden Umfang und das Design der Integrationslösung. Sofern es nötig ist – etwa im Rahmen der Beauftragung von externen Akteuren – ist sie für die Beschaffung der dazu nötigen Ressourcen verantwortlich. Zu besetzen ist diese Rolle somit durch Akteure, die mit den nötigen Weisungsbefugnissen ausgestattet sind, um die mit der Rolle der Integrationsleitung verbundenen Aktivitäten durchführen zu können. Typischerweise ist die Integrationsleitung demzufolge mit Führungsverantwortlichen der Netzwerkpartner zu besetzen.592 Im Falle eines fokal gesteuerten Netzwerks wird dies ein Führungsverantwortlicher des fokalen Partnerunternehmens sein. In poly-

590 591 592

Vgl. Emmelhainz (1990), S. 138. Vgl. Batiste/Jung (1984), S. 217. Zusätzlich stellt die Beteilung des Top-Management an Integrationsprojekten einen zu berücksichtigenden Faktor für dessen erfolgreichen Durchführung dar (vgl. etwa Loh/Koh (2004), S. 34413442).

218

Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken

zentrischen Netzwerken hingegen ist zu erwarten, dass sich die Integrationsleitung aus den am Integrationsprojekt beteiligten Partnerunternehmen zusammensetzt.593 Auf der Stufe der Verantwortlichen im Rahmen der Partnerunternehmen-übergreifenden Integrationsorganisation ist das Integrationskernteam angesiedelt. Wesentliche Aktivitäten des Integrationsvorgehens werden vom Kernteam übernommen. Darin enthalten ist insbesondere die Identifizierung der Integrationsbereiche, deren Evaluation und das Integrations-Assessment.594 Darüber hinaus ist das Integrationskernteam mit der Steuerung der Teilprojekte – etwa im Hinblick auf die zu erstellende Integrations-Spezifikation – betraut. Den Aktivitäten des Integrationskernteams folgend ist es mit Geschäftsleitungsmitgliedern der betroffenen Netzwerkpartner oder den Leitern der betroffenen Fach- und IT-Bereiche zu besetzen.595 Interne sowie insbesondere externe Integrationsexperten unterstützen mitunter das Integrationskernteam.596 Dazu umfasst ihre Kerntätigkeit in der Lieferung vom relevanten Wissen zur Integration bzw. potenziellen Integrationslösungen an das Integrationskernteam. Entsprechend sind die Integrationsexperten durch Akteure mit ausgewiesenen IT- bzw. Integrationskompetenzen zu besetzen. Als Entscheider im Rahmen der Partnerunternehmen-bezogenen Integrationsorganisation ist zunächst die Leitung der Partnerunternehmen hinsichtlich der Netzwerkaktivitäten zu berücksichtigen, d. h. die Vertreter der Partnerunternehmen im Netzwerkmanagement.597 Diese sind insbesondere an der Zieldefinition des Netzwerks sowie an der Entscheidung über die Beteiligung des jeweiligen Partnerunternehmens sowohl nach der Integrationsevaluation als auch nach dem Integrations-Assessment beteiligt. Entsprechend ist die Rolle von Führungsverantwortlichen der jeweiligen Netzwerkpartner zu besetzen. Ist das Top-Management eines Partnerunternehmens allerdings nicht in dessen Netzwerkaktivitäten involviert, wie ist etwa bei Konzernen vorstellbar ist bei denen lediglich ein Bereich einer Tochtergesellschaft an einem Netzwerk teilnimmt, so ist die hierarchisch höchste Stelle innerhalb des jeweiligen Partnerunternehmens, die an den Netzwerkaktivitäten beteiligt ist, von dieser Rolle betroffen. Auf der zweiten Stufe im Rahmen der Partnerunternehmen-bezogenen Integrationsorganisation findet sich die Rolle der Integrationsverantwortlichen innerhalb der betroffenen Partnerunternehmen. Die Kernaufgaben der von dieser Rolle betroffenen

593 594 595

596 597

Vgl. Kapitel 4.6.1. Vgl. Stietz (1995), S. 210. Vgl. Emmelhainz (1990), S. 140-141. Siehe auch Aufgaben und Besetzung der Lenkungsgruppe bei Muschter (1998), S. 184-185. Vgl. Stietz (1995), S. 212. Vgl. Wohlgemuth (2002), S. 140.

Rollenmodell

219

Akteure liegen in der Koordination des Integrationsprojekts innerhalb der jeweils betroffenen Partnerunternehmen. Darunter ist etwa die termingerechte Erreichung und Weiterleitung von Teilergebnissen der Partnerunternehmen zu fassen.598 Entsprechend sind die beteiligten Akteure für die Steuerung von Partnerunternehmenbezogenen Teilprojekten zur Integration verantwortlich. Zu besetzen ist die Rolle der Integrationsverantwortlichen innerhalb der Partnerunternehmen folglich durch leitende Mitarbeiter der Fach- bzw. IT-Bereiche, die über Weisungsbefugnisse verfügen, um die Partnerunternehmen-bezogenen Teilprojekte zu steuern. Auf der Stufe der Unterstützung und damit auf unterster Ebene der Partnerunternehmen-bezogenen Integrationsorganisation ist die Rolle der Beteiligten am Integrationsbereich angesiedelt. Zu unterscheiden sind dabei zum einen die Nutzer der späteren Integrationslösungen, wie etwa in den Fachbereichen sowie zum anderen deren Entwickler bzw. Verantwortliche im Hinblick auf die Weiterentwicklung und Wartung der Lösung. Entsprechend sind die an der Integrationslösung Beteiligten insbesondere in die Identifizierung der Integrationsbereiche – etwa bei der Analyse des Datenflusses – sowie in die Integrationsspezifikation zur Anforderungsermittlung involviert.599 Zu besetzen ist die Rolle der Beteiligten am Integrationsbereich entsprechend durch Mitarbeiter der Fach- und IT-Bereiche der vom Integrationsbereich betroffenen Partnerunternehmen. Mit dem skizzierten Rollenmodell ist die Methodenbeschreibung abgeschlossen und kann im Folgenden einer ersten Evaluation unterzogen werden.

598 599

Vgl. Kremer (2004), S. 121. Vgl. Stietz (1995), S. 212.

5 Evaluation der Integrationsmethode Im Anschluss an die Methodenbeschreibung widmet sich das vorliegende Kapitel der Evaluation der entwickelten Technik. Diese erfolgt im Kern durch den Methodeneinsatz im Rahmen eines konkreten Fallbeispiels mit einem Unternehmensnetzwerk der Automobilzuliefererindustrie. Entsprechend wird in Kapitel 5.1 zunächst das dem Fallbeispiel zugrunde liegende Netzwerk vorgestellt, bei dem die Integrationsmethode durchgeführt wurde. Dieser Einführung folgt in Kapitel 5.2 die Vorstellung der Kernergebnisse des Methodeneinsatzes im Rahmen des Fallbeispiels. Den Abschluss bildet in Kapitel 5.3 die kritische Würdigung der Methode. Dabei werden insbesondere Hinweise auf zwingende sowie optionale Methodenschritte gegeben. 5.1

Einführung in das Fallbeispiel zur Methodenevaluation

Wie beschrieben erfolgte die Evaluation der Methode in einem Unternehmensnetzwerk der Automobilzulieferindustrie.600 Das Fallbeispiel wurde durch eine Reihe von Workshops und Interviews mit den Netzwerkpartnern durchgeführt. Dabei war der Autor entweder selbst beteiligt oder wurde über die Ergebnisse in Form von Protokollen und sonstigen Ergebnisdokumenten informiert. Aus Geheimhaltungsgründen wird das Fallbeispiel in anonymisierter Form sowie hinsichtlich geschäftskritischer Sachverhalte allgemeingültig und abstrakt beschrieben. Das Fallbeispiel ist innerhalb der Automobilzulieferindustrie im Rahmen der Fahrzeugentwicklung angesiedelt. Das Netzwerk bildet dabei eine Reihe von innerhalb Europas verteilten, rechtlich und wirtschaftlich weitgehend selbständigen Unternehmen, die lose miteinander verbunden sind und je nach Auftrag von einem fokalen Partner konfiguriert werden. Entsprechend liegt zwischen den Partnerunternehmen eine weitgehend instabile Konfiguration vor, so dass es sich um ein Projektnetzwerk handelt.601 Dargestellt wird der fokale Partner dabei durch den Automobilhersteller. Da am untersuchten Netzwerk eine Vielzahl von Partnern beteiligt sind – allein am im Rahmen des Fallbeispiels untersuchten Fahrzeugentwicklungsprojekt partizipieren über 15 Netzwerkpartner – wurde der Fokus für die erstmalige Evaluation der Methode auf ein Teilnetzwerk gelegt. Dieses besteht aus drei Netzwerkpartnern, die im Rahmen der Fahrzeugentwicklung intensiv kooperieren. Im Folgenden werden die drei Partner des Teilnetzwerks kurz vorgestellt. Dem „Steuerungsunternehmen“ als erster Partner des Teilnetzwerks unterliegt die gesamte Verantwortung für die Fahrzeugentwicklung des untersuchten Netzwerkauf-

600

601

Zur Einführung in die Fallstudie sowie zu den zentralen Ergebnissen vgl. Schindler (2006), S. 5766. Vgl. Kapitel 2.1.1.3.

222

Evaluation der Integrationsmethode

trags. Die Projektverantwortung wurde dem Unternehmen bis auf wenige Ausnahmen vom Automobilhersteller übertragen. Somit zählt zu den Aufgaben des Steuerungsunternehmens insbesondere die Koordination der an der Fahrzeugentwicklung beteiligten weiteren Netzwerkpartner. Das in Südeuropa ansässige Steuerungsunternehmen beschäftigt insgesamt rund 1.100 Mitarbeiter, mit denen es sich insbesondere auf die Gesamtfahrzeugentwicklung konzentriert. Darüber hinaus gehört zum Teilnetzwerk ein „Innenraumproduzent“. Hinsichtlich des Fallbeispiels ist er entsprechend mit der Entwicklung des Interieurs im Rahmen des untersuchten Netzwerkauftrags betraut. Dabei liegt sein Fokus vor allem auf der Entwicklung des Cockpits. Der Innenraumproduzent ist mit seinen über 30 Niederlassungen neben Europa ebenfalls in Nordamerika sowie im asiatischen Raum angesiedelt und beschäftigt insgesamt rund 18.000 Mitarbeiter. Neben der Entwicklung von Interieursystemen zählt des Weiteren die Entwicklung von Sitz- und Schließsystemen zu seinen maßgeblichen Geschäftsfeldern. Schließlich gehört ein „Entwicklungsdienstleister“ als drittes Unternehmen zum Teilnetzwerk. Der Entwicklungsdienstleister ist im Rahmen des untersuchten Netzwerkauftrags mit der Entwicklung der Komponenten des Fahrzeuginnenraums beschäftigt. Dabei liegt sein wesentlicher Schwerpunkt auf den Bereichen Cockpit sowie Türen- und Seitenverkleidungen. Der Entwicklungsdienstleister beschäftigt rund 250 Mitarbeiter, die sich über sieben Niederlassungen im europäischen Raum verteilen. Allgemein liegt sein Fokus der Entwicklung von Fahrzeuginnenräumen, ausgehend von Konzepten bis hin zu Serienprodukten. Der Entwicklungsdienstleister gehört genauso wie der Innenraumproduzent zu einem übergeordneten Konzern. In diesem stehen die Konzerneinheiten allerdings auf gewissen Märkten in Konkurrenz zueinander, so dass die rechtliche und wirtschaftliche Selbständigkeit zwischen den Unternehmen weitgehend gewährleistet ist.602 5.2

Methodenergebnisse aus dem Fallbeispiel

Im Folgenden wird die Durchführung der fünf Techniken im Rahmen des Fallbeispiels sowie die sich daraus ergebenden Ergebnisdokumente beschrieben.603

Technik 1: Ermittlung der Netzwerkprozessorganisation Gemäß der Integrationsmethode wird im Rahmen der ersten Technik die Ermittlung der Netzwerkorganisation angestrebt. Dazu ist ausgehend vom übergeordneten Ko602

603

Vgl. zur Bedeutung der rechtlichen und wirtschaftlichen Selbständigkeit von Konzerneinheiten und ihrer Zugehörigkeit zum Phänomenbereich der Unternehmensnetzwerke Tröndle (1987), S. 25. Wie beschrieben beziehen sich Methodenergebnisse des Fallbeispiels auf das zuvor skizzierte Teilnetzwerk. Aus Vereinfachungsgründen wird dieses im Folgenden als „Netzwerk“ bezeichnet.

Methodenergebnisse aus dem Fallbeispiel

223

operationszweck und den zugehörigen Netzwerkzielen zunächst auf die wesentlichen Prozesse zu schließen und im Anschluss die jeweils an den Prozessschritten beteiligten Partnerunternehmen aufzudecken. Entsprechend dieser Vorgehensschritte ermittelte das Netzwerk zunächst den übergeordneten Kooperationszweck. Dies erfolgt gemäß der Methode durch die Beleuchtung der Frage nach dem Kernauftrag der Kooperation. Geeinigt wurde sich dabei auf den Kooperationszweck in Form der „Entwicklung eines Nachfolgemodells eines Automobils im Kleinwagensegment zu bestimmten Vorgaben“. Als Basis der im Kooperationszweck enthaltenen Vorgaben wurden die vom Automobilhersteller bestimmten und zu berücksichtigenden Richtlinien für die Fahrzeugentwicklung aufgeführt. Ausgehend vom übergeordneten Kooperationszweck erfolgt gemäß der entwickelten Methode die Ableitung der Netzwerkziele sowie ihre Priorisierung. Allgemein dient dieser Methodenschritt der Möglichkeit, über die Netzwerkziele auf die hervorzuhebenden Prozesse des Netzwerks zu schließen. Indes war es den Netzwerkpartnern des Fallbeispiels möglich, bereits vom Kooperationszweck ausgehend, die relevanten Kernprozesse zu benennen. Aus Effizienzgründen verkürzte das Netzwerk daher den Methodenschritt zur Ermittlung der Netzwerkziele. Nichtsdestotrotz wurden ausgehend vom Kooperationszweck vier hervorzuhebende Ziele erfasst, auf deren Basis sich ebenfalls auf die relevanten Netzwerkprozesse schließen ließ.604 Entsprechend der Methode sind die aufgedeckten Prozesse schließlich gemäß ihrer Relevanz hinsichtlich der Netzwerkziele und des Integrationspotenzials zu evaluieren. Im Fallbeispiel erfolgte diese Evaluation vor allem bezüglich der Bedeutung der Prozesse für das Entwicklungsprojekt und nicht gemäß den zu erwartenden Integrationspotenzialen. Unterstützt wurde die Beurteilung durch eine vom Netzwerk erstellte Checkliste, mit deren Hilfe die Netzwerkpartner jeweils ihre Einschätzung abgeben konnten. Als besonders relevant wurde dabei der „Data-Management Prozess“ identifiziert. Dementsprechend lag dieser den weiteren Schritten der Methodenevaluation zugrunde. In Anlehnung an die entwickelte Methode unterteilte das Netzwerk den DataManagement Prozess im Anschluss in seine Prozesskomponenten. Grundlage dazu bildete eine Reihe von Interviews mit den Prozessbeteiligten. Im Vordergrund standen dabei die Fragen nach den Anfangs- und Endpunkten der Prozesse, den groben

604

Wesentliche Ziele des Netzwerks liegen in der (1) Verbesserung der Zusammenarbeit unter den Entwicklungs- und Produktionsstandorten, (2) besseren Einhaltung der Entwicklungsbudgets, (3) Verbesserung der Erreichung von Qualitätszielen sowie (4) besseren Einhaltung der zeitlichen Vorgaben. Unter Bezugnahme des Kooperationszwecks ermittelte das Netzwerk daraus den (1) Data-, (2) Release- und (3) Change-Management Prozess sowie (4) Kommunikationsprozess des Projekts.

224

Evaluation der Integrationsmethode

Prozessphasen, den einzelnen Prozessschritten sowie Prozessunterschritten. Darüber hinaus ließ sich für die Prozessgliederung auf bereits bestehende Prozessübersichten des Netzwerks zurückgreifen, die im Rahmen der Interviews zu verifizieren waren. Die Prozessgliederung in die einzelnen Prozesskomponenten erfolgte dabei bis zu dem Punkt, an dem sich eine Prozesskomponente überschneidungsfrei einem Partnerunternehmen zuordnen ließ. Zum Abschluss der ersten Technik konnten den ermittelten Prozesskomponenten jeweils die verantwortlichen Partnerunternehmen zugeordnet werden. Dazu stellte das Netzwerk entsprechend der Methode ein Netzwerkprozess-Organisations-Diagramm auf. Technik 2: Identifikation der Integrationsbereiche Gemäß der entwickelten Methode schließt die Technik zur Evaluation der Integrationsbereiche unmittelbar an die Erfassung der Netzwerkprozess-Organisation an. Das Ziel der Technik liegt allgemein in der Aufdeckung von zwei Integrationsbereichstypen, wobei zum einen Integrationsbereiche aufgrund weitgehend fehlender Anwendungssystemunterstützung ganzer Prozesse sowie zum anderen Integrationsbereiche zwischen interdependenten Anwendungssystemen zu ermitteln sind. Diesen Integrationsbereichstypen folgend untersuchte das Netzwerk den DataManagement Prozess zunächst hinsichtlich der bestehenden Anwendungssystemunterstützung. Dazu erstellten die Netzwerkpartner die im Rahmen der Methode vorgestellte Anwendungssystemlandkarte. Diese zeigte, dass der untersuchte Prozess bereits umfangreich durch bestehende Anwendungssysteme unterstützt wurde und somit die Analyse der Interdependenzen zwischen den Systemen nötig war. Entsprechend ermittelte das Netzwerk die bestehenden Kommunikationsbeziehungen zwischen den einzelnen Prozesskomponenten. Dabei wurde indes auf die innerhalb der Methode beschriebene Input-Process-Output-Analyse verzichtet. Dies war möglich, da das Netzwerk auf eine bereits bestehende Übersicht der Input- und Outputbeziehung zwischen den Prozesskomponenten zurückgreifen konnte. Somit stellten die Netzwerkpartner unverzüglich die Matrix zur Erfassung der Kommunikationsbeziehungen auf. Aus dieser ließen sich zwei Kommunikationsbeziehungen für die weitere Durchführung der Methode herausgreifen (vgl. Abb. 5.2/1).

Methodenergebnisse aus dem Fallbeispiel

225

Freigabe Entwicklungsd.

Freigabe Hersteller

Änderung Modulstatus

Paket Prüfung

Entwicklung Vision

Entwicklung Alternative

Modul-Prüfung

Modell Blockierung (freeze)

Modellprüfung

Anforderungsentwicklung

Bereitstellung relevanter Modelldaten

Daten Bereitstellung Modul

ModellEntwicklung

ausgewählte Kommunikationsbeziehungen

Abb. 5.2/1: Informationsfluss des Prozesses Data-Management

Im folgenden Schritt untersuchte das Netzwerk die ausgewählten Kommunikationsbeziehungen auf Automatisierungspotenziale zwischen den beteiligten Anwendungssystemen. Für die Kommunikationsbeziehungen führte es gemäß der Methode jeweils eine Detailanalyse durch. Die Basis der Detailanalyse bildete das Netzwerkprozess-Organisations-Diagramm zur Identifizierung der an der Prozesskomponente beteiligten Netzwerkpartner sowie die Anwendungssystemlandkarte zur Ermittlung der betroffenen Anwendungssysteme. Gemäß der Detailuntersuchung ließen sich drei zu automatisierende Anwendungssystembeziehungen identifizieren (vgl. Abb. 5.2/2). Mit den Detailanalysen der Kommunikationsbeziehungen, die beide als potenzielle Integrationsbereiche angesehen wurden, schloss die Technik ab. Kommunikationsbeziehung 1 zwischen: Modul-Prüfung und Paketprüfung

OutputSysteme

InputSysteme Steuerungsunternehmen AS K

Entwicklungsdienstleister

AS E

A

Innenraumproduzent

AS E

A

Kommunikationsbeziehung 2 zwischen: Paketprüfung und Änderung Modulstatus

OutputSysteme

Steuerungsunternehmen

InputSysteme

Hersteller

AS P

AS K

A

A = Automatisierungspotenzial zwischen AS

Abb. 5.2/2: Detailanalyse der ausgewählten Kommunikationsbeziehungen

Technik 3: Evaluation der Integrationsbereiche Die dritte Technik der Methode zielt allgemein auf die Filterung von Integrationsbereichen, die für das weitere Vorgehen besonders relevant erscheinen. Dazu sind die aufgedeckten Integrationsbereiche allgemein hinsichtlich ihrer Attraktivität und ihrer

226

Evaluation der Integrationsmethode

Bedeutung für das Unternehmensnetzwerk zu beurteilen. Im Rahmen des Fallbeispiels wurde sich dabei auf die Evaluation des Integrationsbereichs aus der ersten Kommunikationsbeziehung beschränkt. Ausgehend von den bereits ermittelten Netzwerkzielen der ersten Technik legte das Netzwerk die kritischen Erfolgsfaktoren für die Zielerreichung fest.605 Im Anschluss daran untersuchten die Partner, inwiefern die Schließung des Integrationsbereichs einen Beitrag zur Zielerreichung des Netzwerks leisten würde. Dabei verzichteten die Partnerunternehmen auf die detaillierte Vergabe von Punkten hinsichtlich des Beitrags des Integrationsbereichs für die jeweiligen Erfolgsfaktoren. Dies erschien insofern sinnvoll, als die Unterstützung der Erfolgsfaktoren durch den Integrationsbereich von allen Partnern von vornherein als wichtig angesehen wurde. Im nächsten Schritt analysierte das Netzwerk den Integrationsbedarf. Gemäß der Methode wurden die Netzwerkpartner dafür nach (1) dem zu verarbeitenden Datenvolumen zwischen den vom Integrationsbereich betroffenen Anwendungssystemen, (2) den zur Datenverarbeitung nötigen Transaktionen, (3) den Möglichkeiten bzw. Wahrscheinlichkeiten von Fehlfunktionen sowie (4) dem Bedarf der Real-timeDatenübertragung befragt. Insbesondere aufgrund des erheblichen Datenvolumens zwischen den beteiligten Anwendungssystemen – übertragen werden täglich etwa 20 GB – und vielen irrelevanten manuellen Schritten im Rahmen der Datenübertragung sowie der Feststellung, dass eine Zeitverzögerung der Datenübertragung nur bedingt akzeptabel ist, wurde der Integrationsbedarf hoch eingeschätzt. Entsprechend stufte das Netzwerk die Bedeutung des Integrationsbereichs im Rahmen des Teilportfolios „Integrationsbedeutung“ als hoch ein. Im Anschluss befasste sich das Netzwerk mit der Erstellung des Teilportfolios „Integrationsattraktivität“. Dazu wurden das Controlling, die Projektleitung, das Qualitätsmanagement, die IT-Bereiche sowie die Geschäftsleitung bezüglich der Projektrisiken und des zu erwartenden Nutzens der Integration befragt. Ergebnis der Ermittlung der Integrationsattraktivität hinsichtlich des Nutzens war unter anderem die Verringerung von Doppelarbeit durch eine automatisierte Lösung um 20% bis 30%, die Vermeidung von Projektabschlusskosten in Höhe von vier Mannmonaten und die Beschleunigung der netzwerkübergreifenden Abläufe um den Faktor zehn. Hingegen wurden die Risiken der Durchführung des Integrationsprojekts verhältnismäßig niedrig eingeschätzt. Dementsprechend wurde dem Integrationsbereich gemäß der Einordnung in das Teilportfolio eine hohe Integrationsattraktivität zugeschrieben.

605

Dabei wurden die (1) Einrichtung einer effizienten IT-Infrastruktur, der (2) automatische CADDatenaustausch sowie die (3) Gewährleistung der Datensicherheit als kritische Erfolgsfaktoren identifiziert.

Methodenergebnisse aus dem Fallbeispiel

227

Im abschließenden Schritt erfolgte die Übertragung des Integrationsbereichs aus den zwei Teilportfolios in das Kombinationsportfolio, bestehend aus den Dimensionen Integrationsattraktivität und Integrationsbedeutung. Da dem untersuchten Integrationsbereich bereits in den Teilportfolios eine hohe Einschätzung zugeschrieben wurde, fiel er im Kombinationsportfolio ebenfalls in den Bereich der weiter zu verfolgenden Integrationsbereiche.

Technik 4: Integrationsspezifikation Im Rahmen der Integrationsspezifikation erfolgt allgemein die Ermittlung des SollKonzepts einer Integrationslösung. In einem ersten Schritt wurde vom Netzwerk dazu die Integrationsvision ermittelt. Im Sinne der Methode dient diese als Orientierungshilfe im weiteren Verlauf der Integrationsspezifikation. Gemäß der Integrationsvision des Fallbeispiels wurde als Ziel festgehalten den „Datenaustausch zwischen den beiden Systemen [...] zu automatisieren, um die vorhandenen Mängel zu beseitigen.“ Angestrebt wurde dabei: x

eine schnellstmögliche Realisierung,

x

die weitgehende Weiterverwendung der Lösung

x

sowie eine effiziente Realisierung und einfache Wartung.

Aufbauend auf der Detailanalyse der Kommunikationsbeziehung aus der zweiten Technik sowie der ermittelten Integrationsvision ließ sich schließlich ein erster Hinweis für die Integrationsarchitektur ableiten. So wurde im Rahmen der Integrationsspezifikation eine Architektur gewählt, die sich mehrheitlich der ApplikationsKommunikation zuordnen ließ. Im Anschluss identifizierte das Netzwerk die relevanten direkten und indirekten Viewpoints zur Anforderungsermittlung. Als direkte Viewpoints wurden zunächst die Entwickler der betroffenen Netzwerkpartner angesehen. Ferner fanden sich relevante Viewpoints in Form des Managements und der IT-Bereiche der betroffenen Netzwerkpartner. Darüber hinaus ließen sich indirekte Viewpoints aufdecken. Darunter fielen zwei zu berücksichtigende Standards zur Speicherung von Geometriedaten, Stücklisten und weiteren Metadaten sowie die Berücksichtigung einer Versionierung einzelner Entwicklungsstände. Ausgehend von den ermittelten Viewpoints führte das Netzwerk im nächsten Schritt eine Schwachstellenanalyse der Ist-Situation durch. Dabei wurde die Ist-Situation hinsichtlich guter, obsoleter sowie mit Schwachstellen versehenen Bestandteilen untersucht (vgl. Abb. 5.2/3).

228

Evaluation der Integrationsmethode

„Guter Teil“

„Obsoleter Teil“

• Standleitung

• Keine

• Die vorhandenen Systeme

„Teil mit Schwachstellen“ Ablauforientierte Schwachstellen • Redundante Datenhaltung: teilweise 20-30% Mehrarbeit • Fehlende Daten: weiterbearbeitete Entwicklungsmodelle wurden überschrieben • Fehlende Funktionen: automatischer Datentransfer • Medienbrüche: zwischen identifizierten Systemen • Hohe Liege-, Bearbeitungs- und Transportzeiten: Entwickler müssen auf ihre Modelle warten, bis die IT- Abteilung diese ins richtige Verzeichnis eingestellt hat Aufbauorientierte Schwachstellen • Ungenügende Abteilungsorganisation: nein • Mangelnde Richtlinien, Vorschriften: nein • Schwachstellen im Berichtswesen: nein • Ungenügende Schnittstellen zu anderen organisatorischen Bereichen: nein Technische Schwachstellen • Mangelnde Hardwareausstattung: keine automatische Schnittstellen • Mangelnde Softwareausstattung: keine automatische Schnittstellen • Fehlende IT-Kompetenz der Mitarbeiter bei den Netzwerkpartnern: nein

Abb. 5.2/3: Beurteilung der Ist-Situation zur Anforderungsermittlung

Aus Effizienzgründen verzichtete das Netzwerk auf eine weitere Detaillierung der Anforderungen. Bereits bekannt war aus der Integrationsvision und Schwachstellenanalyse, dass die Entwicklung einer Schnittstelle angestrebt wurde, die ohne umfangreiche zusätzliche Funktionen die Kommunikation zwischen den betroffenen Systemen ermöglichen sollte. Für die Beurteilung der Wirtschaftlichkeit der angestrebten Integrationslösung im Rahmen der folgenden Technik war die Ermittlung der Integrationsvision, der Viewpoints sowie der angestrebten Integrationsarchitektur und der aufgedeckten Schwachstellen somit ausreichend. Technik 5: Integrations-Assessment Zum Abschluss der Methode erfolgte die wirtschaftliche Bewertung der ausgewählten Integrationslösung. Im Kern sind dabei die erwarteten Kosten- und Nutzeffekte zu erfassen, gegenüberzustellen sowie eine Verteilung der Kosten zwischen den beteiligten Partnern vorzunehmen. Gemäß der Methode hatte das Netzwerk in einem ersten Schritt zunächst die Erhebungsvoraussetzungen zu bestimmen. Dabei kamen die Netzwerkpartner zu verschiedenen Einschätzungen hinsichtlich der Nutzungsdauer der Integrationslösung. Aus diesem Grund wurde beschlossen, die Nutzeffekte für das Steuerungsunternehmen auf vier Jahre zu beschränken. Indes entschieden sich der Innenraumproduzent sowie der Entwicklungsdienstleister für einen zehnjährigen Nutzungszeitraum. Im darauf folgenden Schritt ermittelte das Netzwerk die Kosten der Integrationslösung. Die Basis der Ermittlung bildete laut der entwickelten Methode der TCOAnsatz. Gemäß dem Vorgehen wurde ein einmaliger Investitionsbedarf in Höhe von

Methodenergebnisse aus dem Fallbeispiel

229

604.000 Euro geschätzt, wobei sich mit etwa 400.000 Euro der größte Teil dieser Summe für Personalausgaben ergab. Die laufenden Kosten für die Systemnutzung veranschlagte das Netzwerk mit einer Summe von 27.500 Euro pro Jahr, die insbesondere für Softwareanpassungen, Systemunterhalt und den Systemsupport vorgesehen waren. Der Kostenermittlung folgte die Erfassung des Integrationsnutzens für die jeweiligen Netzwerkpartner. Als wesentliche Treiber der Nutzeffekte sah das Steuerungsunternehmen den Wegfall bisher bestehender Nachbearbeitungsschritte an. Insgesamt bezifferte dieser Netzwerkpartner seine Nutzeffekte gemäß einer ersten Schätzung mit einem Betrag in Höhe von 129.000 Euro für die ersten drei Nutzungsjahre und mit 149.000 Euro für das weitere Nutzungsjahr, da sich dort zusätzliche Projektabschlusskosten einsparen ließen. Der Innenraumproduzent hielt ohne die Einführung der Integrationslösung eine Vielzahl unterschiedlicher Standards bereit. Diese ließen sich erheblich reduzieren, da durch den Einsatz der Integrationslösung unkompliziert weitere Systeme mit unterschiedlichen Standards angeschlossen werden können. Dafür schätzte der Innenraumproduzent seine Einsparungen auf 45.000 Euro pro Jahr. Neben einigen weiteren Nutzeffekten erwartete er darüber hinaus für die ersten vier Jahre zusätzliche Einsparungen in Höhe von 25.000 Euro aufgrund von Produktivitätseffekten. Ingesamt schätzte der Innenraumproduzenten seine Nutzeffekte auf 77.000 Euro für die ersten vier sowie auf 52.000 Euro für die weiteren sechs Nutzungsjahre. Wesentliche Einsparungen für den Entwicklungsdienstleister würden sich schließlich durch den Wegfall von Tätigkeitsschritten ergeben, die ohne die Lösung durchzuführen sind. Darüber hinaus versprach er sich neue Umsatzpotenziale durch die Entwicklung von Schnittstellen für weitere Kundensysteme bzw. Netzwerkpartner. Daraus ermittelte er für die ersten vier Jahre, in denen das Steuerungsunternehmen die Lösung ebenfalls verwendet, insgesamt Nutzeffekte in Höhe von 150.000 Euro. Die Nutzeffekte der weiteren sechs Jahre bezifferte er hingegen mit 105.000 Euro pro Jahr. In einem weiteren Schritt erfolgte die Zusammenfassung der einzelnen Nutzeffekte, die den Gesamtnutzen der Netzwerkpartner innerhalb der bestimmten Nutzungsjahre übersichtsartig zeigt. Im Anschluss daran ließ sich die Gegenüberstellung der Kosten- und Nutzeffekte vornehmen. Gemäß der Methode setzte das Netzwerk dazu zunächst den Kalkulationszinssatz pauschal auf 12% fest. Eine weitere Berücksichtigung der Risiken durch die Anpassung des Kalkulationszinssatzes wurde ferner von den Partnerunternehmen abgelehnt. Hintergrund war die Einschätzung bereits vorsichtig geschätzter Nutzeffekte, so dass eine Anpassung hinsichtlich der Prognoseunsicherheit nicht

230

Evaluation der Integrationsmethode

relevant erschien. Darüber hinaus wurde auf eine Anpassung aufgrund netzwerkspezifischer Risiken verzichtet. Dies erschien den Partnerunternehmen zum einen als sinnvoll, da eine weitere Nutzung der Integrationslösung außerhalb der Netzwerkkonstellation möglich war. Damit wurde eine unspezifische Integrationslösung gewählt. Darüber hinaus wurde die Partnerunternehmen-bezogene Unsicherheit als gering eingeschätzt, da die Partner bereits langfristig miteinander kooperierten. Aus der anschließenden Berechnung ergab sich ein Kapitalwert der Integrationslösung in Höhe von 745.000 Euro. Des Weiteren wurde ermittelt, dass sich die Investitionskosten spätestens im dritten Jahr amortisieren würden. Gemäß der entwickelten Integrationsmethode sind die Investitionskosten schließlich auf die beteiligten Netzwerkpartner zu verteilen. Dabei folgten die Partner entgegn der Methode nicht der nutzenabhängigen Kostenaufteilung. Diese wurde zwar grundsätzlich als möglich erachtet, stellte jedoch nicht die von den Netzwerkpartnern bevorzugte Variante dar. Vielmehr bewertete das Netzwerk die alleinige Übernahme der Kosten durch den Entwicklungsdienstleister als sinnvoll. Dieser strebte die Refinanzierung der Kosten zum einen durch die bereits ermittelten Einsparungen in Höhe von 150.000 Euro jährlich an sowie zum anderen durch eine Vermietung der Systemnutzung an die weiteren Partner. Da die tatsächliche Realisierung des Projekts aussteht, ist die finale Verrechnung der Kosten bisher offen. Nichtsdestotrotz wurden die Methodenkomponenten aus Sicht der beteiligten Unternehmen äußerst positiv bewertet. Der Entwicklungsdienstleister plant darüber hinaus, die Methode zukünftig generell vor bedeutenden zwischenbetrieblichen Projekten durchzuführen, um damit frühzeitig Inte-grationsbereiche aufzudecken und zu vermindern. Dafür erstellte er unmittelbar nach der Durchführung einen Leitfaden mit detaillierten Anweisungen sowie Checklisten und Dokumentvorlagen (Templates) zum vereinfachten Einsatz der Methode. Der Leitfaden wurde ebenfalls den weiteren europäischen IT-Bereichen des Konzerns vorgestellt, zu dem der Entwicklungsdienstleister gehört. 5.3

Kritische Würdigung der Methode

Der Methodenentwicklung ging die Ermittlung von Anforderungen an eine Methode zur Integrationsplanung und Bewertung voraus.606 Im Kern finden sich die ermittelten Anforderungen in der entwickelten Methode wieder: Hinsichtlich der betroffenen Gestaltungsfelder berücksichtigt die Methode zunächst die Anforderung der Unterstützung unterschiedlicher Integrationsmechanismen. Diese erfolgt durch die einbezogenen Integrationsbereichstypen der zweiten Technik

606

Vgl. Kapitel 2.3.

Kritische Würdigung der Methode

231

sowie die Auswahl der übergeordneten Integrationsarchitekturen im Rahmen der Integrationsspezifikation. Ebenfalls beachtet wurde die Anforderung bezüglich der Anpassungsmöglichkeiten bereits bestehender Systeme. Dafür enthält die Methode eine im Rahmen der Integrationsspezifikation durchzuführende Schwachstellenanalyse. Mit deren Hilfe lassen sich explizit zu übernehmende sowie obsolete Teile bzw. zu behebende Schwachstellen der Ist-Situation aufdecken. Hinsichtlich des Vorgehens- und Ergebnismodells wurden als Anforderungen die Unterstützung der Kernaktivitäten (Identifizierung, Konzeption und Bewertung), ein inkrementelles Vorgehen mit Abbruchstellen sowie die zunehmende Detaillierung der Ergebnisdokumente bei zunehmender Projektdauer gefordert. Diese Anforderungen sind ebenfalls in der Methode berücksichtigt. Entsprechend finden sich innerhalb der Methode explizite Hinweise zur Identifizierung von Integrationsbereichen (Technik 2) sowie zur Konzeption (Technik 4) und Bewertung (Technik 3 und 5) einer Integrationslösung. Ebenfalls berücksichtigt die Methode ein inkrementelles Vorgehen sowie die Verankerung von Abbruchstellen. Dies ist etwa bei der zunächst grob erfolgenden Evaluation zur Filterung der relevanten Integrationsbereiche (Technik 2) und der im späteren Verlauf durchzuführenden detaillierten Wirtschaftlichkeitsanalyse (Technik 5) der Fall. Schließlich steigt der Detaillierungsgrad der Ergebnisdokumente mit zunehmendem Methodenverlauf. Dies zeigen etwa die zu Beginn aufzustellenden Portfolios zur Integrationsevaluation, die später durch eine detaillierte Wirtschaftlichkeitsbewertung der Integrationslösung zu ergänzen sind. Für die Techniken wurden die Anforderungen nach einer durchgängig methodischen Unterstützung sowie einem steigenden Detaillierungsgrad aufgestellt. Diese finden sich ebenso in der entwickelten Methode wieder. So sind darin Techniken für sämtliche Aktivitäten des Vorgehensmodells enthalten. Zum Ende der Methode, etwa im Rahmen der Anforderungsspezifikation, findet sich ebenfalls ein steigender Detaillierungsgrad im Vergleich zu den vorgelagerten Techniken. Schließlich wurde für das Rollenmodell die Berücksichtung unterschiedlicher Varianten der Projektorganisation sowie die unterschiedliche Besetzung von Rollen gefordert. Beide Anforderungen ließen sich in der Integrationsmethode ebenfalls berücksichtigen. So finden sich zum einen Hinweise auf eine heterarchische sowie zum anderen auf eine hierarchische Organisationsvariante. Darüber hinaus sind im Rollenmodell unterschiedliche Varianten der zu besetzenden Rollen berücksichtigt, bei denen ebenfalls explizit die Beauftragung externer Akteure thematisiert ist. Die Anwendung der Methode im Rahmen des Fallbeispiels verdeutlicht darüber hinaus deren effizienten Einsatz zur Integrationsplanung und -bewertung innerhalb eines Unternehmensnetzwerks. So ließen sich durch den Methodeneinsatz sowohl Integrationsbereiche des Netzwerks aufdecken, diese evaluieren sowie eine geeig-

232

Evaluation der Integrationsmethode

nete Integrationslösung spezifizieren und die Lösung schließlich wirtschaftlich bewerten. Entsprechend wurde jede der enthaltenen Techniken im Rahmen des Fallbeispiels auf ihre Eignung hin überprüft. Daneben liefert die Methodenanwendung jedoch auch erste Hinweise auf Methodenschritte, die anzupassen bzw. nicht zwingend und damit lediglich optional vom Netzwerk durchzuführen sind. Optionale Schritte liegen typischerweise dann vor, wenn die Ergebnisse dieser Schritte dem Netzwerk bereits bekannt sind oder – etwa aufgrund fokaler Strukturen – netzwerkspezifische Methodenschritte ausgelassen werden. Die Hinweise auf mögliche Methodenanpassungen bzw. optionale Methodenschritte werden im Folgenden skizziert: Optional durchzuführende Methodenschritte finden sich zunächst bei der ersten Technik im Rahmen der Ermittlung der Netzwerkziele. So bedarf es keiner ausführlichen Zieldefinition sowie einer darauf aufbauenden Ableitung der Netzwerkprozesse, wenn dem Netzwerk bereits zu Methodenbeginn die auf Integrationsbereiche zu untersuchenden Prozessschritte bekannt sind.607 Innerhalb der zweiten und den folgenden Techniken liegt der Methode zumindest implizit die Annahme zugrunde, dass grundsätzlich alle Netzwerkpartner an Integrationsprojekten für einen aufgedeckten Integrationsbereich teilnehmen. Hingegen zeigte das Fallbeispiel, dass sich innerhalb des jeweiligen Netzwerks ebenfalls Teilnetzwerke bilden können, für die der Integrationsbereich relevant ist. Wie das Fallbeispiel allerdings ebenfalls zeigt, ist dabei die Realisierung einer Integrationslösung gemäß der Methode nicht gefährdet, sofern ein Integrationsbereich aufgedeckt wurde, der für das jeweilige Teilnetzwerk gravierende wirtschaftliche Nachteile mit sich bringt.608 Offen ist hingegen die Frage, ob das Teilnetzwerk die Einführung der Integrationslösung vornehmen würde, wenn weitere Netzwerkpartner – etwa durch eine vorgelagerte verkürzte Prozesszeit oder eine verminderte Fehlerquote – ebenfalls maßgeblich von der Integrationslösung profitieren.609 Dabei wäre ebenfalls zu klären, inwiefern die bereitgestellten Mechanismen der Integrationsmethode zur Messung des Integrationsnutzens und der Verteilung der Integrationskosten zur Involvierung dieser Netzwerkpartner geeignet sind.

607

608

609

Zu beachten ist dabei allerdings, dass dies Auswirkungen auf die vorgestellte Ermittlung der kritischen Erfolgsfaktoren im Rahmen der zweiten Technik hat und – sofern die kritischen Erfolgsfaktoren des Netzwerks nicht bereits bekannt sind – zu diesem Zeitpunkt nachzuholen wäre. Vgl. dazu Kapitel 4.4.3.2. So besteht in diesem Fall ein großes Interesse des Teilnetzwerks, die Integrationslösung zu realisieren, um damit weiteren wirtschaftlichen Schaden abzuwenden. Hintergrund des Problems ist das typischerweise anzutreffende Verlangen der Netzwerkpartner nach einer gleichmäßigen Nettonutzenverteilung (vgl. Jarillo (1988), S. 36).

Kritische Würdigung der Methode

233

Im Rahmen der dritten Technik findet die Ermittlung der Integrationsbedeutung unter anderem vor dem Hintergrund der kritischen Erfolgsfaktoren des Unternehmensnetzwerks statt. Das vorgestellte Fallbeispiel zeigte jedoch, dass sich die ausführliche Erfassung und Priorisierung der kritischen Erfolgsfaktoren vereinfachen lässt, wenn innerhalb des Netzwerks bereits Einigkeit über die Priorität der Erfolgsfaktoren besteht. Ist dies der Fall, so ist die ausführliche Priorisierung lediglich als optionaler Methodenschritt anzusehen. Unabhängig von der tatsächlich gewählten Lösung schlägt die vierte Technik eine ausführliche Aufstellung der Integrationsspezifikation vor. Das skizzierte Fallbeispiel zeigt jedoch, dass für die weitere erfolgreiche Methodendurchführung ebenfalls eine grobe Spezifikation der Integrationslösung mehrheitlich unter Bezugnahme auf die Integrationsvision, die Beurteilung der indirekten Viewpoints sowie auf die Schwachstellenanalyse als Basis für die Wirtschaftlichkeitsbeurteilung der Integrationslösung ausreichen kann. Dies scheint insbesondere der Fall zu sein, wenn eine Integrationslösung mit geringer Komplexität gewählt wird. Beispielsweise liegt dies bei der einfachen Etablierung einer Schnittstelle zur Applikations-Kommunikation im Vergleich zur Spezifikation einer großintegrierten Applikation zum Applikations-Sharing vor. Nichtsdestotrotz kann die Aufstellung einer detaillierten Anforderungsspezifikation nicht ausgelassen werden. Diese hat spätestens unmittelbar vor der Projektumsetzung – dann aber gegebenenfalls nach der Beurteilung der Wirtschaftlichkeit – zu erfolgen. Innerhalb der Methode wird bisher jedoch nicht hinterfragt, inwiefern das Netzwerk über einen anderen Zeitpunkt für die Anforderungsspezifikation entscheiden kann. Dieser Schritt lässt sich jedoch unkompliziert und ohne weitere Auswirkungen auf die folgenden Methodenschritte nach der Schwachstellenanalyse in die Methode verankern. Schließlich hat die Durchführung der Fallstudie für die fünfte Technik aufgedeckt, dass die beteiligten Netzwerkpartner unterschiedliche Erhebungsvoraussetzungen hinsichtlich der Nutzungsdauer der Integrationslösung haben können. Auch wenn diese Anpassung der Methode keine Änderung des weiteren Methodenverlaufs mit sich bringt, ist die Möglichkeit unterschiedlicher Erhebungszeiträume für die tatsächliche Methodenverwendung explizit zu berücksichtigen. Schließlich ist anzumerken, dass die Überprüfung der Methode im Rahmen eines einzelnen Fallbeispiels erfolgte und entsprechend auf ein einziges Netzwerk einer Branche und auf eine Anwendungssystemlandschaft beschränkt ist. Trotz der erfolgreichen Durchführung der Methode ist insofern noch offen, inwieweit sie sich in weiteren Netzwerken und Branchen und insbesondere bei komplexeren Anwendungssystemlandschaften erfolgreich einsetzen lässt.

6 Schlussbetrachtung Abschließend fasst die Schlussbetrachtung in Kapitel 6.1 zunächst die wichtigsten Ergebnisse der Untersuchung in kompakter Form zusammen. Ausgehend davon werden die Ergebnisse in Kapitel 6.2 einer kritischen Würdigung unterzogen, aus der sich schließlich Ansatzpunkte für weitere Forschungsaktivitäten hinsichtlich des Integrationsvorgehens in Unternehmensnetzwerken ableiten lassen. 6.1

Zusammenfassung der zentralen Ergebnisse

Die vorliegende Arbeit untersuchte den Themenkomplex der Anwendungssystemintegration in Unternehmensnetzwerken, wobei der Fokus insbesondere auf dem methodischen Vorgehen zur Integrationsplanung und -bewertung lag. Ausgehend von der Problemstellung sowie dem Stand der Forschung der Objektbereiche „Unternehmensnetzwerke“ und „Anwendungssystemintegration“ wurde zunächst ein Forschungsdefizit hinsichtlich netzwerkspezifischer Integrationsmethoden aufgedeckt. Demzufolge zielte die Arbeit insbesondere auf die Aufarbeitung des Themenkomplexes der Integrationsmethoden für Unternehmensnetzwerke. Im Kern ließ sich die übergeordnete Zielsetzung in drei Teilziele gliedern. Zunächst sollte dabei ein Verständnis für das in der Praxis anzutreffende Integrationsvorgehen von Netzwerken geschaffen werden, um daraus Anforderungen für eine netzwerkspezifische Integrationsmethode abzuleiten. Darauf aufbauend lag das zweite Ziel in der Überprüfung bestehender Integrationsmethoden gemäß ihrer Eignung für den Einsatz in Unternehmensnetzwerken. Das letzte Ziel der Untersuchung war schließlich die Entwicklung einer Methode zur Integrationsplanung und -bewertung in Unternehmensnetzwerken. Sowohl aufgrund der fehlenden konzeptionellen Basis als auch den geringfügigen empirischen Daten zum Integrationsvorgehen der Praxis wurden für die Erreichung des ersten Ziels zunächst Fallstudien erhoben, aus denen sich induktiv Anforderungen an das Integrationsvorgehen in Netzwerken ableiten ließen. Indes lag für die weitere Zielsetzung ein deduktives Vorgehen nahe, da zum einen das dafür nötige domänenabhängige Vorwissen gegeben war sowie zum anderen auf die Entwicklung von Gestaltungsempfehlungen abgezielt wurde. Ausgehend vom Kooperationsbegriff sowie vom Themenkomplex der Anwendungssysteme erfolgte zu Beginn der Arbeit die Aufarbeitung des Phänomens der zwischenbetrieblichen Integration. In deren Rahmen ließen sich in Form des DatenSharings, der Applikations-Kommunikation und des Applikations-Sharings drei übergeordnete Integrationsarchitekturen für Netzwerke ableiten. Darüber hinaus wurde das Method Engineering vorgestellt. Mittels der Strukturierung von Methoden in fünf Komponenten in Form des (1) Metamodells, (2) Vorgehens- und (3) Ergebnismodells, der (4) zu verwendenden Techniken sowie des (5) Rollenmodells, eignet sich

236

Schlussbetrachtung

das Method Engineering für die detaillierte Analyse und damit den Vergleich von Methoden sowie für die Methodenentwicklung. Ausgehend von diesen Grundlagen wurden anschließend vier Fallstudien zum Integrationsvorgehen von Netzwerken vorgestellt, die gemäß dem Method Engineering in ihre Methodenkomponenten gegliedert wurden. Aus deren Analyse ließen sich schließlich Anforderungen an eine Integrationsmethode für Netzwerke ableiten. Gemäß den Anforderungen hat eine Methode im Kern die (1) Realisierung der drei Integrationsarchitekturen zu unterstützen, (2) im Rahmen eines inkrementellen Vorgehens mit Abbruchstellen die (3) Kernaktivitäten „Identifizierung der Integrationsbereiche“ sowie „Planung und Bewertung der Integrationslösung“ zu berücksichtigen und für (4) sämtliche Aktivitäten geeignete Techniken mit zunehmenden Detaillierungsgrad bereitzustellen. Die Techniken sind darüber hinaus dementsprechend zu gestalten, so dass sich (5) informale Ergebnisdokumente mit zunehmender Projektdauer durch formale Ergebnisdokumente ersetzen lassen. Das Rollenmodell der Methode hat schließlich (6) unterschiedliche Varianten der Projektorganisation sowie der (7) Rollenbesetzung zu enthalten. Ausgehend von den ermittelten Anforderungen ließen sich bestehende Integrationsmethoden hinsichtlich ihrer Eignung für den Einsatz in Netzwerken untersuchen. Dafür wurde zunächst eine Eingrenzung der zu untersuchenden Integrationsmethoden vorgenommen. Diese erfolgte anhand ihrer inhaltlichen (im Sinne der abgedeckten Integrationsobjekte) und strukturellen (im Sinne der beschriebenen Methodenkomponenten) Vollständigkeit. Gemäß dieser Eingrenzung ließen sich vier Methoden für eine vertiefende Analyse ableiten, deren Untersuchung anhand der fünf Komponenten des Method Engineerings erfolgte. Im Kern offenbarte die Analyse ein heterogenes Bild hinsichtlich des von der Literatur empfohlenen Integrationsvorgehens, das darüber hinaus den ermittelten Anforderungen an Integrationsmethoden für Unternehmensnetzwerke kaum gerecht wird. Diesen Ergebnissen entsprechend erfolgte anschließend die Entwicklung eines Methodenansatzes zur Integration in Unternehmensnetzwerken. Als Basis wurden dafür zunächst drei Methodeneckpfeiler vorgestellt, die von sämtlichen Methodenkomponenten zu berücksichtigen waren. Im Kern umfassten diese Eckpfeiler die (1) konsequente Berücksichtigung netzwerkspezifischer Besonderheiten, die (2) Fokussierung der Integrationsplanung und -bewertung sowie eine (3) konsequente Managementorientierung und damit die weitgehende Vermeidung eines auf technische Details zielenden Vorgehens. Daraus ließ sich die Integrationsmethode für Unternehmensnetzwerke darstellen. Deren Strukturierung erfolgte dabei anhand der fünf Komponenten des Method Engineerings. Den Schwerpunkt bildet dabei insbesondere das bereitgestellte Set der Integrationstechniken. Diese dienen zunächst der Ermittlung der Netzwerkprozessorganisation, auf der aufbauend sich unter Zuhilfenahme der

Zusammenfassung der zentralen Ergebnisse

237

bestehenden Anwendungssystemlandschaft des Netzwerks die Integrationsbereiche identifizieren lassen. Ebenfalls enthalten ist eine Technik, die dem Netzwerk eine grundsätzliche Evaluation der ermittelten Integrationsbereiche ermöglicht. Diese erfolgt im Kern anhand der Beurteilung der jeweiligen Integrationsattraktivität (zusammengesetzt aus Integrationsrisiko und Integrationsnutzen) sowie der Integrationsbedeutung (zusammengesetzt aus Zielunterstützung des Integrationsbereichs sowie dem jeweiligen Integrationsbedarf). Für die vom Netzwerk weiter verfolgten Integrationsbereiche wird darüber hinaus eine Technik zur detaillierten Anforderungserfassung einer Integrationslösung bereitgestellt sowie deren systematische Spezifikation und Validierung vorgenommen. Schließlich findet sich im Rahmen der entwickelten Methode eine Technik, mittels der eine ausführliche Wirtschaftlichkeitsbewertung des Integrationsbereichs ermöglicht wird. Im Kern erfolgt dies durch die Gegenüberstellung der zunächst erfassten Integrationskosten und des Integrationsnutzens, der anschließenden Auswahl einer zur realisierenden Integrationslösung sowie der netzwerkspezifischen Verrechnung der Integrationskosten. Abschließend wurde die entwickelte Methode im Rahmen eines Fallbeispiels auf ihre Eignung untersucht. Die Untersuchung zeigte, dass sich die bereitgestellten Methodenbestandteile ohne Komplikationen in der Praxis bewähren. Der praktische Methodeneinsatz offenbarte ebenfalls, dass einige der enthaltenen Schritte im Netzwerk lediglich optional durchgeführt werden können. Dies ist insbesondere der Fall, wenn ein Netzwerk bereits über Ergebnisse verfügt, etwa durch den Einsatz anderer Managementinstrumente, die sich ebenfalls als Zwischenergebnisse der Methode eignen. Darüber hinaus ließen sich erste Hinweise auf mögliche Ansatzpunkte für Anpassungen der entwickelten Methodenschritte aufzeigen. Insbesondere wurde dabei die Frage nach den möglichen Auswirkungen der Bildung von Teilnetzwerken innerhalb des Netzwerks auf die erfolgreiche Methodendurchführung aufgeworfen. Dabei zeigte sich ein Ansatzpunkt für die Anpassung hinsichtlich der Reihenfolge der enthaltenen Methodenschritte. Zusammenfassend besteht der Forschungsbeitrag dieser Arbeit gemäß der zugrunde liegenden Zielsetzung zunächst in der Ermittlung von ersten Erkenntnissen bezüglich des Integrationsvorgehens in der Netzwerkpraxis und der daraus erfolgten Ableitung von Anforderungen an eine netzwerkspezifische Integrationsmethode. Weitere Forschungsbeiträge liegen in deren Gegenüberstellung mit den bestehenden Integrationsmethoden der Literatur und schließlich der Entwicklung und Evaluation eines netzwerkspezifischen Ansatzes zur Integrationsplanung und -bewertung. Nichtsdestotrotz unterliegen diese Ergebnisse einigen Einschränkungen, auf die im folgenden Abschnitt hingewiesen wird und aus denen sich schließlich ein weiterer Forschungsbedarf ableiten lässt.

238

6.2

Schlussbetrachtung

Kritische Würdigung und weiterer Forschungsbedarf

Der auf den Erkenntnissen zum einen des Integrationsvorgehens in der Netzwerkpraxis sowie zum anderen der bestehenden Integrationsmethoden aufbauende Methodenansatz beinhaltet umfangreiche Vorgehenshinweise für die Integrationsplanung und -bewertung in Unternehmensnetzwerken. Hinsichtlich dieser Ergebnisse sind jedoch einige einschränkende Aspekte zu beachten, die durchaus kritisch gesehen werden können und einen Anstoß für weiteren Forschungsbedarf geben. So ist zunächst die begrenzte Anzahl der Fallstudien zur Ermittlung der Anforderungen an Integrationsmethoden als einschränkend anzusehen. Entsprechend ist zu berücksichtigen, dass die Analyse weiterer Integrationsprojekte in Netzwerken mitunter zusätzliche Anforderungen aufdecken sowie die Relevanz der ermittelten Anforderungen reduzieren kann. Bereits im Rahmen der Untersuchung wurden durch die Untersuchung möglichst heterogener Netzwerke bzw. Integrationsprojekte erste Maßnahmen zur Eindämmung dieses Kritikpunktes vorgenommen. Aufgrund der fehlenden konzeptionellen Basis hinsichtlich des Integrationsvorgehens in der Netzwerkpraxis war die Durchführung einer großzahlig empirischen Erhebung sowie ihre statistische Auswertung vor der Untersuchung noch nicht möglich. Aufbauend auf den im Rahmen der Untersuchung explorativ ermittelten Anforderungen an eine Integrationsmethode bietet sich ihre empirische Untersuchung als weiterer Forschungsbedarf an. Als ebenfalls einschränkend ist die begrenzte Auswahl der analysierten Integrationsmethoden aufzuführen. So wurde im Rahmen der Auswahl bestehender Integrationsmethoden lediglich auf wissenschaftlich geprägte Ansätze zurückgegriffen. Zu erwarten ist allerdings auch, dass sich in der Praxis – und dort insbesondere bei ITnahen Beratungsunternehmen – methodisches Know-how hinsichtlich der Anwendungssystemintegration findet, das für die Methodenentwicklung ebenfalls als fruchtbar zu erachten ist. Eine Reihe der im Rahmen der Untersuchung vorgenommenen Maßnahmen vermindert indes diesen Kritikpunkt, ohne ihn jedoch vollständig auszuräumen. So ließen sich mittels der durchgeführten Fallstudien zum einen Erkenntnisse über das Integrationsvorgehen in der Praxis sammeln, woran zum Teil ebenfalls externe Projektbeteiligte in Form von Unternehmensberatungen beteiligt waren. Darüber hinaus bilden die untersuchten Integrationsmethoden der Literatur nicht die alleinige Grundlage der entwickelten Methode. Wie beschrieben flossen in die Methodenentwicklung Erkenntnisse aus verwandten Disziplinen ein, wie etwa aus dem Software Engineering sowie dem Geschäftsprozess- und Netzwerkmanagement. Dabei wurde ebenfalls praxisnahe Literatur, wie entsprechende Handbücher oder Leitfäden berücksichtigt. Schließlich konnte die entwickelte Methode im Rahmen einer Fallstudie auf ihre Tauglichkeit in der Praxis geprüft werden, womit ein weiterer Praxisbezug hergestellt wurde.

Kritische Würdigung und weiterer Forschungsbedarf

239

Darüber hinaus müssen sich konstruktionsorientierte Arbeiten und damit auch die vorliegende Untersuchung typischerweise die Kritik einer fehlenden methodischen Strenge gefallen lassen.610 Ein Kernpunkt dieser Kritik zielt auf die verminderte Eindeutigkeit bzw. Nachvollziehbarkeit der gewählten Konstruktionselemente solcher Arbeiten. Hinsichtlich dieser Problematik ist für die vorliegende Untersuchung offen, inwiefern sich weitere oder anders eingesetzte Methodenkomponenten ebenfalls zur Integrationsplanung und -bewertung in Unternehmensnetzwerken eignen. Ohne diese Kritik vollends beheben zu können, zeigt der erfolgreiche Methodeneinsatz im Rahmen der durchgeführten Evaluation zunächst die grundsätzliche Eignung der erarbeiteten Methodenkomponenten für die Integrationsplanung und -bewertung in Netzwerken. Daneben offenbart sich jedoch auch noch ein weiterer Forschungsbedarf hinsichtlich der entwickelten Methode. So wäre zu überprüfen, inwiefern weitere oder veränderte Methodenkomponenten zu einer verbesserten Integrationsmethode für Netzwerke führen können. Schließlich ließen sich die weiterentwickelten sowie unter Umständen völlig neuen Ansätze zu einer netzwerkspezifischen Integrationsmethode mit allgemeingültigem Charakter im Sinne eines Referenzmodells verarbeiten. 611 Bereits im Rahmen der Evaluation der Integrationsmethode wurde wiederum auf die geringe Fallzahl hingewiesen. So kann die einmalig erfolgte Durchführung der Integrationsmethode lediglich erste Hinweise auf ihre tatsächliche Eignung in der Praxis geben. Diese werden indes durch das Vorhaben eines der beteiligten Partnerunternehmen verstärkt, die Integrationsmethode zukünftig zu Beginn bedeutender zwischenbetrieblicher Projekte durchzuführen. Nichtsdestotrotz lassen sich kaum fundierte Aussagen zu ihrer Eignung treffen, ohne zusätzliche Evaluationen der Methode durchzuführen. Dabei ist sie etwa auf ihre Tauglichkeit in weiteren Netzwerken mit unterschiedlicher Stabilität und Steuerungsform, unterschiedlichem Branchenfokus sowie unterschiedlich gewählten Integrationsarchitekturen zu untersuchen.

610

611

Dieser Kritikpunkt berührt insbesondere die „Rigor versus Relevance“-Debatte im Rahmen der anglo-amerikanischen Disziplin der Information Systems (vgl. etwa Hevner et al. (2004)). Vgl. zu Referenzmodellen etwa Mertens et al. (2005), S. 177-178.

Literaturverzeichnis Albers, S./Bisping, D./Teichmann, K./Wolf, J. (2003): Management Virtueller Unternehmen, in: Albers, S./Wolf, J. (Hrsg.): Management Virtueller Unternehmen, Wiesbaden, S. 3-60. Alt, R./Cäsar, M./Leser, F./Österle, H./Puschmann, T./Reichmayr, C./Zurmühlen, R. (2004): Methode zur Entwicklung von Prozessportalen, in: Alt, R./Österle, H. (Hrsg.): Real-time Business, Lösungen, Bausteine und Portale des Business Networking, Berlin, S. 257-281. Alt, R./Legner, C./Österle, H. (2005): Virtuelle Organisation - Konzept, Realität und Umsetzung, in: HMD Theorie und Praxis der Wirtschaftsinformatik, 42. Jg., Nr. 242, S. 7-20. Antweiler, J. (1995): Wirtschaftlichkeitsanalyse von Informations- und Kommunikationssystemen (IKS): Wirtschaftlichkeitsprofile als Entscheidungsgrundlage, Köln. Armour, P. (2005): Project Portfolios: Organizational Management of Risk, in: Communications of the ACM, 48. Jg., Nr. 3, S. 17-20. Arnold, O./Faisst, W./Härtling, M./Sieber, P. (1995): Virtuelle Unternehmen als Unternehmenstyp der Zukunft?, in: HMD Theorie und Praxis der Wirtschaftsinformatik, 32. Jg., Nr. 185, S. 8-23. Auth, G./Frie, T. (2001): Kopplung operativer (horizontaler) Applikationen mit dem Data Warehouse, Arbeitsbericht des Instituts für Wirtschaftsinformatik der Universität St. Gallen, St. Gallen. Bach, V./Brecht, L./Hess, T./Österle, H. (1996): Enabling Systematic Business Change, Integrated Methods and Software Tools for Business Process Redesign, Wiesbaden. Balke, N./Küpper, H.-U. (2003): Controlling in Netzwerken: Strukturen und Systeme, in: Zentes, J./Swoboda, B./Morschaett, D. (Hrsg.): Kooperationen, Allianzen und Netzwerke, Wiesbaden, S. 941-963. Balzert, H. (2000): Lehrbuch der Software-Technik: Software-Entwicklung, 2. Auflage, Heidelberg. Batiste, J./Jung, J. (1984): Requirements, Needs, and Priorities: A Structured Approach for Determining MIS Project Definition, in: MIS Quarterly, 8. Jg., Nr. 4, S. 215-227. Bayerlein, P. (2005): Five Steps To Strategy Planning, in: Strategic Communication Management, 9. Jg., Nr. 5, S. 6-7. Bea, F./Dichtl, E./Schweitzer, M. (2001): Allgemeine Betriebswirtschaftslehre Bd. 2: Führung, 8., neubearbeitete und erweiterte Auflage, Stuttgart. Bea, F./Göbel, E. (1999): Organisation, Theorie und Gestaltung, Stuttgart. Becker, J. (1991): CIM-Integrationsmodell - Die EDV-gestützte Verbindung betrieblicher Bereiche, Berlin. Becker, J./Algermissen, L./Delfmann, P./Falk, T./Niehaves, B. (2005): Identifikation von Best Practices durch Geschäftsprozessmodellierung in öffentlichen Ver-

242

Literaturverzeichnis

waltungen, in: HMD - Praxis der Wirtschaftsinformatik, 42. Jg., Nr. 241, S. 86-96. Becker, J./Holten, R./Knackstedt, R./Niehaves, B. (2004): Epistemologische Positionierungen in der Wirtschaftsinformatik am Beispiel einer konsensorientierten Informationsmodellierung, in: Frank, U. (Hrsg.): Wirtschaftstheorie in Ökonomie und Wirtschaftsinformatik, Wiesbaden, S. 335-366. 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, Arbeitsbericht Nr. 77 des Instituts für Wirtschaftsinformatik der Westfälischen Wilhelms-Universität Münster, Münster. Becker, N. (1999): Regelungsfelder für Unternehmensnetzwerke, Wiesbaden. Benz, R. (2001): Entwurf überbetrieblicher Prozessnetzwerke, Bamberg. Berander, P./Andrews, A. (2005): Requirements Priorization, in: Aurum, A./Wohlin, C. (Hrsg.): Engineering and Managing Software Requirements, Berlin, S. 69-94. Berg, C. (1981): Organisationsgestaltung, Stuttgart. Best, E./Weth, M. (2005): Geschäftsprozesse optimieren: der Praxisleitfaden für erfolgreiche Reorganisation, 2., überarbeitete Auflage, Wiesbaden. Biehl, M./Kim, H. (2003): Electronic marketplaces versus enterprise resource planning: a comparison and decision methodology for supply chain management, in: International Journal of Technology, Policy and Management, 3. Jg., Nr. 3/4, S. 262-284. Bienert, M. (2002): Organisation und Netzwerk: Organisationsgestaltung durch Annäherung an Charakteristika der idealtypischen Organisationsform Netzwerk, Wiesbaden. Biethahn, J./Mucksch, H./Ruf, W. (2000): Ganzheitliches Informationsmanagement Band 1: Grundlagen, 5. Auflage, München. Bleicher, K. (1991): Organisation: Strategien - Strukturen - Kulturen, 2. Auflage, Wiesbaden. Blyth, A. (1999): Using Stakeholders, Domain Knowledge, and Responsibilities to Specify Information Systems' Requirements, in: Journal of Organizational Computing and Electronic Commerce, 9. Jg., Nr. 4, S. 287-296. Boehm, B. (1984): Verifiying and validating software requirements and design specifications, in: IEEE Software System Design, 1. Jg., Nr. 1, S. 75-88. Böhm, R./Fuchs, E./Pacher, G. (1996): System-Entwicklung in der Wirtschaftsinformatik, 4. Auflage, Zürich. Bonoma, T. (1985): Case Research in Marketing: Opportunities, Problems and a Process, in: Journal of Marketing Research, 22. Jg., Nr. 2, S. 199-208. Borgatti, S. P./Foster, P. C. (2003): The Network Paradigm in Organizational Research: A Review and Typology, in: Journal of Management, 29. Jg., Nr. 6, S. 991-1013. Braun, C./Wortmann, F./Hafner, M./Winter, R. (2005): Method construction - a core approach to organizational engineering, Proceedings of the 2005 ACM symposium on Applied computing.

Literaturverzeichnis

243

Brenner, C. (1995): Techniken und Metamodell des Business Engineering, Bamberg. Brenner, W. (1994): Grundzüge des Informationsmanagements, Berlin. Bresser, R. (1989): Kollektive Unternehmensstrategien, in: Zeitschrift für Betriebswirtschaft, 59. Jg., Nr. 5, S. 545-564. Brockhaus, R. (1992): Informationsmanagement als ganzheitliche, informationsorientierte Gestaltung von Unternehmen: organisatorische, personelle und technische Aspekte, Göttingen. Burghardt, M. (2002): Projektmanagement: Leitfaden für die Planung, Überwachung und Steuerung von Entwicklungsprojekten, 6. Auflage, Erlangen. Burghardt, M. (2003): Innovative Technologien in virtuellen Netzwerken - Einsatzmöglichkeiten von XML, Web Services und OLAP, Arbeitsbericht Nr. 10/2003 des Instituts für Wirtschaftsinformatik II der Georg-August-Universität Göttingen, Göttingen. Burghardt, M./Gehrke, N./Hagenhoff, S./Schumann, M. (2003): Spezifika und Abwicklung von Workflows auf Basis von Web-Services, in: HMD - Praxis der Wirtschaftsinformatik, 40. Jg., Nr. 234, S. 61-69. Buss, M. (1983): How to rank computer projects, in: Harvard Business Review, 61. Jg., Nr. 1, S. 118-125. Cash, J./McFarlan, W./McKenney, J. L. (1992): Corporate Information Systems Management: The Issues Facing Senior Executives, 3. Auflage, Homewood. Chalmers, A. (2001): Wege der Wissenschaft: Einführung in die Wissenschaftstheorie, 5., völlig überarbeitete und erweiterte Auflage, Berlin. Chen, P. P.-S. (1976): The Entity-Relationship Model - Toward a Unified View of Data, in: ACM Transactions on Database Systems, 1. Jg., Nr. 1, S. 9-36. Chmielewicz, K. (1994): Forschungskonzeptionen der Wirtschaftswissenschaften, 3., unveränderte Auflage, Stuttgart. Ciborra, C./Jelassi, T. (1994): Strategic Information Systems: a European perspective, West Sussex. Cooke-Davies, T. (2002): The "real" success factors on projects in: International Journal of Project Management, 20. Jg., Nr. 3, S. 185-190. Corsten, H. (1997): Geschäftsprozessmanagement - Grundlagen, Elemente und Konzepte, in: Corsten, H. (Hrsg.): Management von Geschäftsprozessen: Theoretische Ansätze - Praktische Beispiele, Stuttgart, S. 9-57. Corsten, H. (2001): Unternehmensnetzwerke, Formen unternehmungsübergreifender Zusammenarbeit, München. Corsten, H./Gössinger, R. (2001): Einführung in das Supply-Chain-Management, München. Daenzer, W./Huber, F. (1999): Systems Engineering: Methodik und Praxis, Zürich. Dangelmaier, W./Lessing, H./Pape, U./Rüther, M. (2002): Klassifikation von EAISystemen, in: HMD Theorie und Praxis der Wirtschaftsinformatik, 39. Jg., Nr. 225, S. 61-71.

244

Literaturverzeichnis

Daniel, E./White, A./Ward, J. (2004): Exploring the role of third parties in interorganizational Web service adoption, in: Journal of Enterprise Information Management, 17. Jg., Nr. 5, S. 351-360. Das, T./Teng, B. (1996): Risk Types and the inter-firm Alliance Structures, in: Journal of Management Studies, 33. Jg., Nr. 6, S. 827-843. Davenport, T. (1993): Process Innovation - Reengineering Work through Information Technology, Boston. Davenport, T./Short, J. (1990): The New Industrial Engineering: Information Technology and Business Process Redesign, in: Sloan Management Review, 31. Jg., Nr. 4, S. 11-22. Davidow, W./Malone, M. (1993): Das virtuelle Unternehmen: Der Kunde als CoProduzent, Frankfurt. Donzelli, P. (2004): A goal-driven and agent-based requirements engineering framework, in: Requirements Engineering, 9. Jg., Nr. 1, S. 16-39. Eberhard, K. (1999): Einführung in die Erkenntnis- und Wissenschaftstheorie : Geschichte und Praxis der konkurrierenden Erkenntniswege, 2., durchgesehene und erweiterte Auflage, Stuttgart. Eberlein, A./Leite, J. (2002): Agile Requirements Definition: A View from Requirements Engineering, Proceedings of the International Workshop on TimeConstrained Requirements Engineering (TCRE’02), Essen. Ebers, M./Gotsch, W. (2001): Institutionenökonomische Theorien der Organisation, in: Kieser, A. (Hrsg.): Organisationstheorien, Stuttgart, S. 199-251. Ebers, M./Hermesch, M./Matzke, M./Mehlhorn, A. (2000): Strukturwandel und Steuerungsformen von Netzwerken in der deutschen Bauindustrie, in: Sydow, J./Windeler, A. (Hrsg.): Steuerung von Netzwerken, Opladen, S. 251-279. Ebert, C. (2005): Systematisches Requirements Management: Anforderungen ermitteln, spezifizieren, analysieren und verfolgen, Heidelberg. Eckert, S./Schissler, M./Ferstl, O. K. (2004): Einsatz einer Entwicklungsmethodik für die überbetriebliche Integration von Anwendungssystemen im Rahmen einer Fallstudie aus der Automobilzuliefererindustrie, in: Bartmann, D./Mertens, P./Sinz, E. (Hrsg.): Überbetriebliche Integration von Anwendungssystemen: FORWIN-Tagung 2004, Aachen, S. 41-59. Eckert, S./Schissler, M./Mantel, S./Schäffner, C. (2003): Entwicklung von Kopplungsarchitekturen - Evaluierung einer Methodik anhand eines Beispiels aus der Automobilzulieferindustrie, in: Sinz, E./Plaha, M./Neckel, P. (Hrsg.): Modellierung betrieblicher Informationssysteme - MobIS 2003, Bamberg, S. 87-107. Eckert, S./Suchan, C./Ferstl, O./Schissler, M. (2005): Integration von Anwendungssystemen für die Materialwirtschaft - Anwendung einer Entwicklungsmethodik im Bereich des Kraftwerksbau, Wirtschaftsinformatik 2005 eEconomy, eGovernment, eSociety. Emmelhainz, M. (1990): Electronic Data Interchange, A Total Management Guide, New York. Enz, R. (2006): Risikomanagement in ERP Projekten – Ein Konzept am Beispiel eines deutschen Automobilherstellers in: Lehner, F./Nösekabel,

Literaturverzeichnis

245

H./Kleinschmidt, P. (Hrsg.): Mulitikonferenz Wirtschaftsinformatik 2006 - Tagungsband 1, Passau, S. 219-235. Erdmann, L. (2004): Methodik, Aufbau und Umsetzung einer modernen IT-Strategie, in: Zarnekow, R./Brenner, C./Grohmann, H. (Hrsg.): Informationsmanagement - Konzepte und Strategien für die Praxis, Heidelberg, S. 73-91. Faisst, W. (1997): Information Technology as an Enabler of Virtual Enterprises: A Life-Cycle Oriented Description, in: Proceedings of IT Vision'97, The European Conference on Virtual Enterprises and Networked Solutions, Paderborn. Fank, M. (1996): Einführung in das Informationsmanagement: Grundlagen, Methoden, Konzepte, München. Ferstl, O. (1992): Integrationskonzepte Betrieblicher Anwendungssysteme, Fachberichte Informatik - Universität Koblenz-Landau, 1/92, Koblenz. Ferstl, O./Sinz, E. (2001): Grundlagen der Wirtschaftsinformatik Band 1, 4. Auflage, München. Fischer, J. (1993): Unternehmensübergreifende Datenmodellierung - der nächste folgerichtige Schritt der zwischenbetrieblichen Datenverarbeitung!, in: Wirtschaftsinformatik, 35. Jg., Nr. 3, S. 241-254. Fischer, J. (1999): Informationswirtschaft: Anwendungsmanagement, München. Fleisch, E. (2001): Das Netzwerkunternehmen, Strategien und Prozesse zur Steigerung der Wettbewerbsfähigkeit in der "Networked Economy", Berlin. Fleisch, E./Österle, H. (2004): Auf dem Weg zum Echtzeit-Unternehmen, in: Alt, R./Österle, H. (Hrsg.): Real-time Business: Lösungen, Bausteine, Potenziale des Business Networking, Berlin, S. 3-17. Franz, A. (2003): Management von Business Webs: das Beispiel von Technologieplattformen für mobile Dienste, Wiesbaden. Friedrich, J.-M. (2002): Supplychainmanagementsoftware für kleine und mittlere Unternehmen - Lösungsmöglichkeiten mit Componentware, Aachen. Gabriel, R./Beier, D. (2003): Informationsmanagement in Organisationen, Stuttgart. Gaitanides, M. (1983): Prozeßorganisation: Entwicklung, Ansätze, und Programme prozessorientierter Organisationsgestaltung, München. Gaitanides, M./Scholz, R./Vrohlings, A. (1994): Prozeßmanagement - Grundlagen und Zielsetzungen, in: Gaitanides, M./Scholz, R./Vrohlings, A./Raster, M. (Hrsg.): Prozeßmanagement: Konzepte, Umsetzungen und Erfahrungen des Reengineering, München, S. 1-36. Gassner, C. (1996): Konzeptionelle Integration heterogener Transaktionssysteme, Bamberg. Gehra, B. (2005): Früherkennung mit Business-Intelligence-Technologien: Anwendung und Wirtschaftlichkeit der Nutzung operativer Datenbestände, Wiesbaden. Gerpott, T./Böhm, S. (2000): Strategisches Management in virtuellen Unternehmen, in: Albach, H./Specht, D./Wildemann, H. (Hrsg.): Virtuelle Unternehmen. Ergänzungsheft 2/2000 der Zeitschrift für Betriebswirtschaft, Wiesbaden, S. 1335.

246

Literaturverzeichnis

Gerpott, T./Wittkemper, G. (1995): Business Process Redesign, in: Nippa, M./Picot, A. (Hrsg.): Prozeßmanagement und Reengineering: die Praxis im deutschsprachigen Raum, Frankfurt, S. 144-164. Göbel, E. (2002): Neue Instiutionenökonomik, Stuttgart. Goeken, M. (2004): Anforderungsmanagement bei der Entwicklung von Data Warehouse-Systemen - Ein sichtenspezifischer Ansatz, in: Schelp, J./Winter, R. (Hrsg.): Auf dem Weg zur Integration Factory - Proceedings der DW2004 Data Warehousing und EAI, Heidelberg, S. 167-186. Gorla, N./Lam, Y. W. (2004): Who should work with whom? Building effective Software Project Teams, in: Communications of the ACM, 47. Jg., Nr. 6, S. 7982. Graaf, B./Lormans, M./Toetenel, H. (2003): Embedded Software Engineering: The State of the Practice, in: IEEE Software, 20. Jg., Nr. 6, S. 61-69. Grant, G. (2003): Strategic alignment and enterprise systems implementation: the case of Metalco, in: Journal of Information Technology, 18. Jg., Nr. 3, S. 159174. Greiffenberg, S. (2003): Methoden als Theorien der Wirtschaftsinformatik, in: Uhr, W./Esswein, W./Schoop, E. (Hrsg.): Wirtschaftsinformatik 2003, Medien Märkte - Mobilität, Band 2, Heidelberg, S. 947-968. Greiner, U./Rahm, E. (2004): Quality-Oriented Handling of Exceptions in WebService-Based Cooperative Processes, in: Hasselbring, W./Reichert, M. (Hrsg.): EAI 2004 – Enterprise Application Integration: Tagungsband des GI/GMDS-Workshops EAI’04, OFFIS, Oldenburg, 12. – 13. Februar 2004, Oldenburg, S. 11-18. Grob, H. L./Reepmeyer, J./Bensberg, F. (2004): Einführung in die Wirtschaftsinformatik, 5. Auflage, München. Grochla, E. (1974): Integrierte Gesamtmodelle der Datenverarbeitung: Entwicklung und Anwendung des Kölner Integrationsmodells (KIM), München. Grochla, E. (1975): Betriebliche Planung und Informationssysteme, Reinbek bei Hamburg. Gutzwiller, T. (1994): Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen, Heidelberg. Hage, M./Metken, M. (1990): Integrierte IV-Anwendungsplanung, in: Information Management, 5. Jg., Nr. 4, S. 54-61. Halaris, C./Kerridge, S. (2003): An Integrated System Supporting Virtual Consortia in the Construction Sector, in: Journal of Organizational Computing and Electronic Commerce, 13. Jg., Nr. 3/4, S. 243-265. Hamel, G./Doz, Y. L./Prahalad, C. K. (1989): Collaborate with Your Competitors - and Win, in: Harvard Business Review, 67. Jg., Nr. 1, S. 133-139. Hamel, W. (1992): Zielsysteme, in: Frese, E. (Hrsg.): Handwörterbuch der Organisation, Stuttgart, Sp. 2634-2652. Hammer, M. (1990): Reengineering Work: Don't Automate, Obliterate, in: Harvard Business Review, 68. Jg., Nr. 4, S. 104-112.

Literaturverzeichnis

247

Hammer, M. (2001): The Superefficient Company, in: Harvard Business Review, 79. Jg., Nr. 8, S. 82-91. Hammer, M./Champy, J. (1994): Business reengineering: die Radikalkur für das Unternehmen, 4. Auflage, Frankfurt. Härder, T. (1990): Die Rolle der Datenbanksysteme in CIM, in: Krallmann, H. (Hrsg.): CIM - Expertenwissen für die Praxis, München, S. 265-277. Haselbauer, H. (1986): Das Informationssystem als Erfolgsfaktor der Unternehmung: Entwicklung eines Bewertungskonzepts, Spardorf. Hauschildt, J. (1977): Entscheidungsziele - Zielbildung in innovativen Entscheidungsprozessen: theoretische Ansätze und empirische Prüfung, Tübingen. Heilmann, H. (1989): Integration: Ein zentraler Begriff der Wirtschaftsinformatik im Wandel der Zeit, in: HMD Theorie und Praxis der Wirtschaftsinformatik, 26. Jg., Nr. 150, S. 46-58. Heinrich, L. (2002): Informationsmanagement: Planung, Überwachung und Steuerung der Informationsinfrastruktur, 7. Auflage, München. Heinzel, H. (2001): Supply Chain Management und das SCOR-Modell - Ein Methodenframework für wettbewerbsfähige Netzwerke, in: Arnold, U./Mayer, R./Urban, G. (Hrsg.): Supply Chain Management – Unternehmensübergreifende Prozesse, Kollaboration, IT-Standards, Bonn, S. 46-68. Heinzl, A./König, W./Hack, J. (2001): Erkenntnisziele der Wirtschaftsinformatik in den nächsten drei und zehn Jahren, in: Wirtschaftsinformatik, 43. Jg., Nr. 3, S. 223-233. Henderson, J./Venkatraman, N. (1999): Strategic alignment: Leveraging information technology for transforming organizations, in: IBM Systems Journal, 38. Jg., Nr. 2/3, S. 472-484. Hess, T. (1996): Entwurf betrieblicher Prozesse: Grundlagen - bestehende Methoden - neue Ansätze, Wiesbaden. Hess, T. (1999): ZP-Stichwort: Unternehmensnetzwerke, in: Zeitschrift für Planung, 10. Jg., Nr. S. 225-230. Hess, T. (2002a): Netzwerkcontrolling, Instrumente und ihre Werkzeugunterstützung, Wiesbaden. Hess, T. (2002b): Planning and Control of Virtual Corporations in the Service Industry: The Prototype VICOPLAN, Proceeding of the 35th Hawaii International Conference on System Sciences, Hawaii. Hess, T./Wittenberg, S. (2005): IT-gestütztes Netzwerkcontrolling, in: HMD - Praxis der Wirtschaftsinformatik, 42. Jg., Nr. 242, S. 52-62. Hevner, A. R./March, S. T./Park, J./Ram, S. (2004): Design Science in Information Systems Research, in: MIS Quarterly, 28. Jg., Nr. 1, S. 75-105. Heym, M. (1993): Methoden-Engineering, Spezifikation und Integration von Entwicklungsmethoden für Informationssysteme, Hallstadt. Heym, M. (1995): Prozeß- und Methodenmanagement für Informationssysteme, Überblick und Referenzmodell, Berlin.

248

Literaturverzeichnis

Hilbers, K. (1992): Entwicklung eines Idealmodells des InformationssystemManagement, Bamberg. Hildebrand, K. (1995): Informationsmanagement: wettbewerbsorientierte Informationsverarbeitung, München. Hill, W./Fehlbaum, R./Ulrich, P. (1989): Organisationslehre 1, 4. Auflage, Bern. Hippe, A. (1997): Interdependenzen von Strategie und Controlling in Unternehmensnetzwerken, Wiesbaden. Hirnle, C. (2006): Bewertung unternehmensübergreifender IT-Investitionen: Ein organisationsökonomischer Zugang, Wiesbaden. Hirnle, C./Hess, T. (2004): Rationale IT-Investitionsentscheidungen: Hürden und Hilfsmittel, in: Zeitschrift für Controlling und Management, 48. Jg., Sonderheft 1/2004, S. 86-95. Ho, L./Lin, G. (2004): Critical success factor framework for the implementation of integrated-enterprise systems in the manufacturing environment, in: International Journal of Production Research, 42. Jg., Nr. 17, S. 3731-3742. Hoffmann, F./Brauweiler, H.-C./Wagener, R. (1996): Computergestützte Informationssysteme, Einführung in die Bürokommunikation und Datentechnik für Wirtschaftswissenschaftler, München. Hofmann, H. (2000): Requirements Engineering: a situated discovery process, Wiesbaden. Hofmann, H./Lehner, F. (2001): Requirements Engineering as a Success Factor in Software Projects, in: IEEE Software, 18. Jg., Nr. 4, S. 58-66. Hohler, B./Villinger, U. (1998): Normen und Richtlinien zur Prüfung und Qualitätssicherung von Steuerungssoftware, in: Informatik-Spektrum, 21. Jg., Nr. 2, S. 63-72. Holland, C. P./Lockett, A. G. (1992): Planning for Electronic Data Interchange, in: Strategic Management Journal, 13. Jg., Nr. 7, S. 539-550. Holten, R. (2003): Integration von Informationssystemen, in: Wirtschaftsinformatik, 45. Jg., Nr. 1, S. 41-52. Holten, R./Schulze, M. (2001): Integriertes Controlling für Aufbau, Betrieb und Anpassung von Supply Chains, in: Wirtschaftsinformatik, 43. Jg., Nr. 6, S. 579588. Hsieh, C./Lin, B. (2003): Web-based data warehousing: Current status and perspective, in: The Journal of Computer Information Systems, 43. Jg., Nr. 2, S. 1-8. Hull, E./Jackson, K./Dick, J. (2005): Requirements Engineering, second Edition, London. IBM (1984): Business Systems Planning: Information Systems Planning Guide, Atlanta. IEEE (1998a): IEEE Guide for Developing System Requirements Specifications, Std. 1233-1998, New York. IEEE (1998b): IEEE Recommended Practice for Software Requirements Specifications, Std. 830-1998, New York.

Literaturverzeichnis

249

Irani, Z./Goheim, A./Love, P. (2006): Evaluating Cost Taxonomies for Information Systems Management, in: European Journal of Operational Research, 173. Jg., Nr. 3, S. 1103-1122. Jacob, A.-F./Klein, S./Nick, A. (1994): Basiswissen Investition und Finanzierung: Finanzmanagement in Theorie und Praxis, Wiesbaden. Janson, M. (1986): Applying a pilot system and prototyping approach to systems development and implementation, in: Information & Management, 10. Jg., Nr. 4, S. 209-216. Jarillo, J. (1988): On Strategic Networks, in: Strategic Management Journal, 9. Jg., Nr. 1, S. 31-41. Jarillo, J./Ricart, J. (1987): Sustaining Networks, in: Interfaces, 17. Jg., Nr. 1, S. 8291. Jeffery, M./Leliveld, I. (2004): Best Practices in IT Portfolio Management, in: MIT Sloan Management Review, 45. Jg., Nr. 3, S. 41-49. Jung, H. (2004): Allgemeine Betriebswirtschaftslehre, 9. Auflage, München. Jung, R. (1995): Projekt-Priorisierung beim integrationsorientierten Reengineering, in: Huber-Wäschle, F./Schauer, H./Widmayer, P. (Hrsg.): GISI 95 – Herausforderungen eines globalen Informationsverbundes für die Informatik, Berlin, S. 544-551. Jung, R. (2001): Gestaltung einer datenintegrierten Architektur für dispositive und operative Zwecke, in: HMD Theorie und Praxis der Wirtschaftsinformatik, 38. Jg., Nr. 222, S. 29-37. Kaib, M. (2002): Enterprise Application Integration, Grundlagen, Integrationsprodukte, Anwendungsbeispiele, Wiesbaden. Katzy, B. (2005): IT-Werkzeuge für virtuelle Organisationen - eine strategische Sicht, in: HMD - Praxis der Wirtschaftsinformatik, 42. Jg., Nr. 242, S. 42-51. Keller, W. (2002): Enterprise Application Integration - Erfahrungen aus der Praxis, Heidelberg. Kemmner, G.-A./Gillessen, A. (2000): Virtuelle Unternehmen: ein Leitfaden zum Aufbau und zur Organisation einer mittelständischen Unternehmenskooperation, Heidelberg. Kimm, R./Koch, W./Simonsmeier, W./Tontsch, F. (1979): Einführung in Software Engineering, Berlin. Klein, S. (1996): Interorganisationssysteme und Unternehmensnetzwerke, Wiesbaden. Klotz, M./Strauch, P. (1990): Strategieorientierte Planung betrieblicher Informationsund Kommunikationssysteme, Berlin. Köhler, H.-D. (2000): Netzwerksteuerung und/oder Konzernkontrolle? Die Automobilkonzerne im Internationalisierungsprozeß, in: Sydow, J./Windeler, A. (Hrsg.): Steuerung von Netzwerken, Opladen, S. 281-300. Kontos, G. (2004): Bewertung des Erfolgs von Unternehmensnetzwerken in der F&E, Aachen.

250

Literaturverzeichnis

Koreimann, D. S. (2000): Grundlagen der Software-Entwicklung, 3., überarbeitete und erweiterte Auflage, München. Kosiol, E. (1968): Grundlagen und Methoden der Organisationsforschung, 2. Auflage, Berlin. Kotonya, G./Sommerville, I. (1996): Requirements Engineering With Viewpoints, in: Software Engineering Journal, 11. Jg., Nr. 1, S. 5-18. Kotonya, G./Sommerville, I. (2002): Requirements Engineering: Processes and Techniques, Chichester. Kraege, R. (1997): Controlling strategischer Unternehmenskooperationen: Aufgaben, Instrumente und Gestaltungsempfehlungen, München. Krcmar, H. (2003): Informationsmanagement, 3. Auflage, Berlin. Krcmar, H./Buresch, A. (1994): IV-Controlling: Ein Rahmenkonzept für die Praxis, in: Controlling, 6. Jg., Nr. 5, S. 294-304. Krebs, M./Rock, R. (1994): Unternehmungsnetzwerke - eine intermediäre oder eigenständige Organisationsform?, in: Sydow, J./Windeler, A. (Hrsg.): Management interorganisationaler Beziehungen - Vertrauen, Kontrolle und Informationstechnik, Opladen, S. 322-345. Kremer, S. (2004): Information Retrieval in Portalen: Gestaltungselemente, Praxisbeispiele und Methodenvorschlag, Bamberg. Krüger, W. (1980): Zielbildung und Bewertung in der Organisationsplanung, Wiesbaden. Krüger, W. (1994): Organisation der Unternehmung, 3. Auflage, Stuttgart. Krumbiegel, J. (1997): Integrale Gestaltung von Geschäftsprozessen und Anwendungssystemen in Dienstleistungsbetrieben, Wiesbaden. Kudrna, J. (2005): Identifikation von Integrationsbereichen in Unternehmensnetzwerken, Diplomarbeit am Institut für Wirtschaftsinformatik und Neue Medien der Ludwig-Maximilians-Universität München, München. Kumar, K./van Hillegersberg, J. (2000): ERP Experiences and Evolution, in: Communications of the ACM, 43. Jg., Nr. 4, S. 22-26. Kurbel, K./Rautenstrauch, C. (1996): Integration Engineering: Konkurrenz oder Komplement zum Information Engineering? - Methodische Ansätze zur Integration von Informationssystemen, in: Heilmann, H. (Hrsg.): Information Engineering: Wirtschaftsinformatik im Schnittpunkt von Wirtschafts-, Sozial- und Ingenieurwissenschaften, München, S. 185-191. Lankes, J./Matthes, F./Wittenburg, A. (2005): Softwarekartographie: Systematische Darstellung von Anwendungslandschaften, in: Ferstl, O./Sinz, E./Eckert, S./Isselhorst, T. (Hrsg.): Wirtschaftsinformatik 2005: eEconomy, eGovernment, eSociety, 7. internationale Tagung Wirtschaftsinformatik, Bamberg, S. 1443-1462. Lederer, A./Sethi, V. (1988): The Implementation of Strategic Information Systems Planning Methodologies, in: MIS Quarterly, 12. Jg., Nr. 3, S. 444-461. Legner, C. (1999): Benchmarking informationssystemgestützter Geschäftsprozesse: Methode und Anwendung, Wiesbaden.

Literaturverzeichnis

251

Lehner, F./Auer-Rizzi, W./Bauer, R./Breit, K./Lehner, J./Reber, G. (1991): Organisationslehre für Wirtschaftsinformatiker, München. Linß, H. (1995): Integrationsabhängige Nutzeffekte der Informationsverarbeitung: Vorgehensmodell und empirische Ergebnisse, Wiesbaden. Linthicum, D. (2000): Enterprise Application Integration, Boston. Loh, T./Koh, S. (2004): Critical elements for a successful enterprise resource planning implementation in small-and medium-sized enterprises, in: International Journal of Production Research, 42. Jg., Nr. 17, S. 3433-3455. Loose, A./Sydow, J. (1994): Vertrauen und Ökonomie in Netzwerkbeziehungen Strukturationstheoretische Betrachtungen, in: Sydow, J./Windeler, A. (Hrsg.): Management interorganisationaler Beziehungen - Vertrauen, Kontrolle und Informationstechnik, Opladen, S. 160-193. Love, P./Irani, Z./Edwards, Z. (2005): Research the investment of information technology in construction: An examination of evaluation practices, in: Automation and Construction, 14. Jg., Nr. 4, S. 569-582. Lutz, V. (1993): Horizontale strategische Allianzen: Ansatzpunkte zu ihrer Institutionalisierung, Hamburg. Ma, C./Chou, D./Yen, D. (2002): Data warehousing, technology assessment and management, in: Industrial Management & Data Systems, 100. Jg., Nr. 3/4, S. 125-134. Mag, W. (1995): Unternehmensplanung, München. Mantel, S./Eckert, S./Schissler, M./Ferstl, O. K./Sinz, E. J. (2002): Entwicklungsmethodik für überbetriebliche Kopplungsarchitekturen von Anwendungssystemen, FORWIN-Bericht-Nr.: 2002-009, Bamberg. Mantel, S./Eckert, S./Schissler, M./Schäffner, C./Ferstl, O./Sinz, E. (2004): Eine Entwicklungsmethodik für die überbetriebliche Integration von Anwendungssystemen, in: Bartmann, D./Mertens, P./Sinz, E. (Hrsg.): Überbetriebliche Integration von Anwendungssystemen: FORWIN-Tagung 2004, Aachen, S. 21-59. Mantel, S./Knobloch, B./Rüffer, T./Schissler, M./Schmitz, K./Ferstl, O. K./Sinz, E. J. (2000): Analyse der Integrationspotenziale von Kommunikationsplattformen für verteilte Anwendungssysteme, FORWIN-Bericht-Nr.: FWN-2000-009, Bamberg. Mantel, S./Schissler, M. (2002): Application Integration, in: Wirtschaftsinformatik, 44. Jg., Nr. 2, S. 171-174. Martin, J. (1990): Information Engineering. Book II: Planning and Analysis, Englewood Cliffs. McFarlan, F. W./McKenney, J. L./Pyburn, P. (1983): The information archipelago-plotting a course, in: Harvard Business Review, 61. Jg., Nr. 1, S. 145-156. Mertens, P. (1966): Die zwischenbetriebliche Kooperation und Integration bei der automatisierten Datenverarbeitung, Meisenheim am Glan. Mertens, P. (1999): Integration interner, externer, qualitativer und quantitativer Daten auf dem Weg zum Aktiven MIS, in: Wirtschaftsinformatik, 41. Jg., Nr. 5, S. 405-415.

252

Literaturverzeichnis

Mertens, P. (2004): Integrierte Informationsverarbeitung 1 - Operative Systeme in der Industrie, 14. Auflage, Wiesbaden. Mertens, P./Bodendorf, F./König, W./Picot, A./Schumann, M./Hess, T. (2005): Grundzüge der Wirtschaftsinformatik, 9., überarbeitete Auflage, Berlin. Mertens, P./Griese, J./Ehrenberg, D. (1998): Virtuelle Unternehmen und Informationsverarbeitung, Berlin. Mertens, P./Schumann, M./Hohe, U. (1989): Informationstechnik als Mittel zur Verbesserung der Wettbewerbsposition - Erkenntnisse aus einer Beispielsammlung, in: Spermann, K./Zur, E. (Hrsg.): Informationstechnologie und strategische Führung, Wiesbaden, S. 109-135. Michaelis, E. (1985): Organisation unternehmerischer Aufgaben - Transaktionskosten als Beurteilungskriterium, Frankfurt. Monczka, R./Carter, J. (1988): Implementing Electronic Data Interchange, in: Journal of Purchasing and Materials Management, 24. Jg., Nr. 2, S. 2-9. Morgan, G. (1980): Paradigms, Metaphors and Puzzle Solving in Organisation Theory, in: Administrative Science Quarterly, 25. Jg., Nr. 4, S. 605-622. Morris, P. W. G./Jamieson, A. (2005): Moving From Corporate Strategy To Project Strategy, in: Project Management Journal, 36. Jg., Nr. 4, S. 5-18. Mucksch, H./Behme, W. (2000): Das Data Warehouse-Konzept als Basis einer unternehmensweiten Informationslogistik, in: Mucksch, H./Behme, W. (Hrsg.): Das Data Warehouse-Konzept, Architektur - Datenmodelle - Anwendungen, Wiesbaden, S. 3-80. Müller-Tengelmann (1994): Kollektive Investitionsstrategien: der elektronische Datenaustausch als überbetriebliche Infrastruktur, Frankfurt. Müller, A. (2005): Wirtschaftlichkeit der Integration: Eine ökonomische Analyse der Standardisierung betrieblicher Anwendungssysteme, Wiesbaden. Müller,

A./Lang, J./Hess, T. (2003): Wirtschaftlichkeit von ControllingAnwendungssystemen: Konzeption und Erprobung eines MultiperspektivenAnsatzes, in: Zeitschrift für Controlling und Management (ZfCM), 47. Jg., Nr. 2, S. 58-66.

Müller, E. (1988): Software-Engineering als kreativer Prozess: Meta-Kriterien für die Entwicklung von Informatiklösungen, Bern. Muschter, S. (1998): IS-gestütztes Prozessmanagement, Wiesbaden. Nagel, K. (1990): Nutzen der Informationsverarbeitung: Methoden zur Bewertung von strategischen Wettbewerbsvorteilen, Produktivitätsverbesserungen und Kosteneinsparungen, 2., überarbeitete und erweiterte Auflage, München. Nagel, P. (1992): Technik der Zielformulierung, in: Frese, E. (Hrsg.): Handwörterbuch der Organisation, Stuttgart, Sp. 2626-2634. Nah, F./Lau, J./Kuang, J. (2001): Critical factors for successful implementation of enterprises systems, in: Business Process Management Journal, 7. Jg., Nr. 3, S. 285-296. Neu, P. (1991): Strategische Informationssystem-Planung: Konzepte und Instrumente, Berlin.

Literaturverzeichnis

253

Niemann, H./Hasselbring, W./Wendt, T./Winter, A./Meierhofer, M. (2002): Kopplungsstrategien für Anwendungssysteme im Krankenhaus, in: Wirtschaftsinformatik, 44. Jg., Nr. 5, S. 425-434. Nolte, H. (1999): Organisation: ressourcenorientierte Unternehmensgestaltung, München. Nuseibeh, B./Easterbrook, S. (2000): Requirements engineering: a roadmap, Proceedings of the Conference on The Future of Software Engineering 2000. Odell, J. (1996): A Primer to Method Engineering, in: Brinkkemper, S./Lyytinen, K./Welke, R. (Hrsg.): Method Engineering – Principles of method construction and tool support, Proceedings of the IFIP TC8 WG8.1/8.2 Working Conference on Method Engineering 26.-28. August 1996, Atlanta, S. 1-7. Odendahl, C. (2001): Planung und Steuerung dynamischer Kooperationsnetzwerke, in: HMD Praxis der Wirtschaftsinformatik, 38. Jg., Nr. 219, S. 72-83. Österle, H. (1995): Business Engineering - Prozeß- und Systementwicklung, Band 1: Entwurfstechniken, Berlin. Österle, H./Brenner, W./Hilbers, K. (1991): Unternehmensführung und Informationssystem: Der Ansatz des St. Galler Informationssystem-Managements, Stuttgart. Palanisamy, R. (2005): Strategic information systems planning model for building flexibility and success, in: Industrial Management & Data Systems, 105. Jg., Nr. 1, S. 63-81. Pant, S./Ravichandran, T. (2001): A framework for information systems planning for e-business, in: Logistics Information Management, 14. Jg., Nr. 2, S. 85-98. Partsch, H. (1991): Requirements Engineering, München. Parviainen, P./Hulkko, H./Kääriänen, J./Takalo, J./Tihinen, M. (2003): Requirements Engineering: Inventory of technologies, Oulu. Parviainen, P./Tihinen, M./van Solingen, R. (2005): Requirements Engineering: Dealing with the Complexity of Sociotechnical Systems Development, in: Luis Mate, J./Silva, A. (Hrsg.): Requirements Engineering for Sociotechnical Systems, Hershey, S. 1-20. Payton, C. F. (2000): Lessons learned from three interorganizational health care information systems, in: Information & Management, 37. Jg., Nr. 6, S. 311-321. Perridon, L./Steiner, M. (2004): Finanzwirtschaft der Unternehmung, 13., überarbeitete und erweiterte Auflage, München. Petri, C. (1990): Externe Integration der Datenverarbeitung, Unternehmensübergreifende Konzepte für Handelsunternehmen, Berlin. Pfeffers, K./Gengler, C./Tuunanen, T. (2003): Extending Critical Success Factors Methodology to Facilitate Broadly Participative Information Systems Planning, in: Journal of Management Information Systems, 20. Jg., Nr. 1, S. 5185. Pfeiffer, W./Dögl, R. (1999): Das Technologie-Portfolio-Konzept zur Beherrschung der Schnittstelle Technik und Unternehmensstrategie, in: Hahn, D./Taylor, B. (Hrsg.): Strategische Unternehmungsplanung - strategische Unternehmungsführung: Stand und Entwicklungstendenzen, Heidelberg, S. 440-468.

254

Literaturverzeichnis

Pfohl, H.-C./Stölzle, W. (1996): Planung und Kontrolle - Konzeption, Gestaltung, Implementierung, München. Picot, A./Dietl, H./Franck, E. (2005): Organisation: Eine ökonomische Perspektive, 4., überarbeitete und erweiterte Auflage, Stuttgart. Picot, A./Franck, E. (1995): Prozeßorganisation, Eine Bewertung der neuen Ansätze aus Sicht der Organisationslehre, in: Nippa, M./Picot, A. (Hrsg.): Prozeßmanagement und Reengineering: Die Praxis im deutschsprachigen Raum, Frankfurt, S. 13-38. Picot, A./Neuburger, R. (2001): Virtuelle Organisationsformen im Dienstleistungssektor, in: Bruhn, M./Meffert, H. (Hrsg.): Handbuch Dienstleistungsmanagement, Wiesbaden, S. 803-823. Picot, A./Reichwald, R./Wigand, R. (2003): Die grenzenlose Unternehmung, Information, Organisation und Management, 5. Auflage, Wiesbaden. Pietsch, T. (2003): Bewertung von Informations- und Kommunikationssystemen: ein Vergleich betriebswirtschaftlicher Verfahren, 2., neu bearbeitete und erweiterte Auflage, Berlin. Porter, M. (1990): The Competitive Advantage of Nations, London. Porter, M./Millar, V. (1985): How information gives you competitive advantage, in: Harvard Business Review, 63. Jg., Nr. 4, S. 149-174. Potthof, I. (1998): Kosten und Nutzen der Informationsverarbeitung: Analyse und Beurteilung von Investitionsentscheidungen, Wiesbaden. Powell, W. (1990): Neither Market nor Hierarchy: Network Forms of Organization, in: Research in Organizational Behavior, 12. Jg., Nr. 10, S. 295-336. Pribilla, P. (2000): Führung in virtuellen Unternehmen, in: Albach, H./Specht, P./Wildemann, H. (Hrsg.): Virtuelle Unternehmen: Zeitschrift für Betriebswirtschaft. Ergänzungsheft 2/2000, Wiesbaden, S. 1-12. Puschmann, T. (2003): Collaboration Portale, Architektur, Integration, Umsetzung und Beispiele, Bamberg. Puschmann, T./Alt, R. (2004): Enterprise Application Integration Systems and Architecture - The Case of the Robert Bosch Group, in: Journal of Enterprise Information Management, 17. Jg., Nr. 2, S. 105-116. Raasch, J. (1991): Systementwicklung mit Strukturierten Methoden. Ein Leitfaden für Praxis und Studium, München. REFA (1985): Methodenlehre der Organisation für Verwaltung und Dienstleistung Teil 3 Aufbauorganisation, Verband für Arbeitsstudien und Betriebsorganisation e.V., München. Reichmann, T. (2001): Controlling mit Kennzahlen und Managementberichten: Grundlagen einer Systemgestützten Controlling-Konzeption, 6., überarbeitete und erweiterte Auflage, München. Reichmayr, C. (2003): Collaboration und WebServices, Architekturen, Portale, Techniken und Beispiele, Berlin. Reichwald, R. (1987): Einsatz moderner Informations- und Kommunikationstechnik: Modell einer Wirtschaftlichkeitsberechnung, in: CIM Management, 3. Jg., Nr. 3, S. 6-11.

Literaturverzeichnis

255

Reischer, J. (2004): Der Informationsbegriff der Alltagssprache – ein Wittgensteinsches Familienähnlichkeitskonzept, in: Bekavac, B./Herget, J./Rittberger, M. (Hrsg.): Informationen zwischen Kultur und Marktwirtschaft. Proceedings des 9. Internationalen Symposiums für Informationswissenschaft (ISI 2004), Chur, S. 85-91. Reiß, M. (2000): Koordinatoren in Unternehmensnetzwerken, in: Kaluza, B./Blecker, T. (Hrsg.): Produktions- und Logistikmanagement in Virtuellen Unternehmen und Unternehmensnetzwerken, Berlin, S. 217-248. Riedl, R. (1991): Strategische Planung von Informationssystemen: Methoden zur Entwicklung von langfristigen Konzepten für die Informationsverarbeitung, Heidelberg. Ring, K. (2000): EAI - Making the right Connections, Boston. Ringel, C./Hansemann, K.-W./Boysen, N. (2005): Erfolgswirkung einer Partizipation an Virtuellen Unternehmen, in: Zeitschrift für Planung und Unternehmenssteuerung, 16. Jg., Nr. 2, S. 147-166. Ringlstetter, M. (1997): Organisation von Unternehmen und Unternehmensverbindungen: Einführung in die Gestaltung der Organisationsstruktur, München. Rockart, J. (1979): Chief Executives define their own data needs, in: Harvard Business Review, 14. Jg., Nr. 2, S. 81-93. Roll, M. (2003): Fallstudien als Instrument der Controllingforschung - Ein Überblick zu ihrer Einordnung, Beurteilung und Durchführung, in: Zeitschrift für Controlling und Management (ZfCM), 47. Jg., Nr. 5, S. 315-317. Rotering, J. (1990): Forschungs- und Entwicklungskooperationen zwischen Unternehmen. Eine empirische Analyse, Stuttgart. Rupp, C. (2004): Requirements-Engineering und -Management: Professionelle, iterative Anforderungsanalyse für die Praxis, München. Rupprecht-Däullary, M. (1994): Zwischenbetriebliche Kooperationen: Möglichkeiten und Grenzen durch Informations- und Kommunikationstechnologie, Wiesbaden. Salmela, H./Spil, T. (2002): Dynamic and emergent information systems strategy formulation and implementation, in: International Journal of Information Management, 22. Jg., Nr. S. 441-460. Schanz, G. (1988): Methodologie für Betriebswirte, 2., überarbeitete und erweiterte Auflage, Stuttgart. Scheckenbach, R. (1997): Semantische Geschäftsprozessintegration, Wiesbaden. Scheer, A.-W. (1991): Architektur integrierter Informationssysteme: Grundlagen der Unternehmensmodellierung, Berlin. Scheer, A.-W. (1998): ARIS - Modellierungsmethoden, Metamodelle, Anwendungen, Berlin. Scheer, A.-W. (2002): ARIS - Vom Geschäftsprozess zum Anwendungssystem, 4., durchgesehen Auflage, Berlin. Schindler, M. (2006): Bewertung von Integrationsbereichen: Entwicklung und Evaluation einer Vorgehensweise für Unternehmensnetzwerke am Fallbeispiel eines Automobilzulieferernetzwerks, Diplomarbeit am Institut für Wirtschaftsinfor-

256

Literaturverzeichnis

matik und Neue Medien der Ludwig-Maximilians-Universität München, München. Schissler, M./Zeller, T./Mantel, S. (2004): Überbetriebliche Integration von Anwendungssystemen: Klassifikation von Integrationsproblemen und -lösungen, in: Bartmann, D./Mertens, P./Sinz, E. J. (Hrsg.): Überbetriebliche Integration von Anwendungssystemen, FORWIN-Tagung 2004, Aachen, S. 1-19. Schmelzer, H. J./Sesselmann, W. (2006): Geschäftsprozessmanagement in der Praxis: Kunden zufrieden stellen, Produktivität steigern, Wert erhöhen, 5., vollständig überarbeitete Auflage, München. Schnell, R./Hill, P./Esser, E. (2005): Methoden der empirischen Sozialforschung, 7. Auflage, München. Schnupp, P./Floyd, C. (1979): Software: Programmentwicklung und Projektorganisation, 2., durchgesehen Auflage, Berlin. Schober, F./Raupp, M. (2003): Coordination Strategies for Interorganizational Networks: A Strategic Framework Based on Network Structure, Frankfurt. Schönherr, M./Gallas, B. (2003): Komponentenbasiertes EAI-Framework unter Einsatz und Erweiterung von Web Services, in: Uhr, W./Esswein, W./Schoop, E. (Hrsg.): Wirtschaftsinformatik 2003, Medien - Märkte - Mobilität, Band 2, Dresden, S. 125-142. Schräder, A. (1996): Management virtueller Unternehmungen: organisatorische Konzeption und informationstechnische Unterstützung flexibler Allianzen, Frankfurt. Schreyögg, G. (2003): Organisation: Grundlagen moderner Organisationsgestaltung, 4. Auflage, Wiesbaden. Schuh, G./Millarg, K./Göransson, A. (1998): Virtuelle Fabrik: Neue Marktchancen durch dynamische Netzwerke, München. Schulte-Zurhausen, M. (2002): Organisation, 3., überarbeitete Auflage, München. Schulze, C./Koller, W. (2002): Vorgehensweise bei EAI-Projekten - Theorie und Praxis, in: HMD Theorie und Praxis der Wirtschaftsinformatik, 39. Jg., Nr. 225, S. 114-123. Schumann, M. (1992): Betriebliche Nutzeffekte und Strategiebeiträge der großintegrierten Informationsverarbeitung, Berlin. Schumann, M./Hess, T./Wittenberg, S./Burghardt, M./Wilde, T. (2004): Management von virtuellen Unternehmen: Softwareunterstützung und innovative Technologien, Göttingen. Schumann, M./Schüle, H./Schumann, U. (1994): Entwicklung von Anwendungssystemen, Grundzüge eines werkzeuggestützten Vorgehens, Berlin. Schwarze, J. (1998): Informationsmanagement: Planung, Steuerung, Koordination und Kontrolle der Informationsversorgung im Unternehmen, Herne. Schweitzer, M. (2000): Gegenstand und Methoden der Betriebswirtschaftslehre, in: Bea, F./Dichtl, E./Schweitzer, M. (Hrsg.): Allgemeine Betriebswirtschaftslehre, Band 1: Grundfragen, Stuttgart, S. 23-79. Schweitzer, M./Küpper, H.-U. (2003): Systeme der Kosten- und Erlösrechnung, 8., überarbeitete und erweiterte Auflage, München.

Literaturverzeichnis

257

Schwinn, A. (2003): Logische Datenintegrationstypen, in: Schelp, J./Winter, R. (Hrsg.): Frühjahrskonferenz 2003 des GI Arbeitskreis Enterprise Architecture (EA), Weiterbildungszentrum (WBZ) der Universität St. Gallen, S. 10-18. Schwinn, A./Schelp, J. (2003): Data Integration Patterns, in: A., W. (Hrsg.): BIS 2003 Department of Management Information Systems at the Poznan University of Economics, Poznan, S. 232-238. Semlinger, K. (2003): Effizienz und Autonomie in Zulieferungsnetzwerken - Zum strategischen Gehalt von Kooperation, in: Sydow, J. (Hrsg.): Management von Netzwerkorganisationen, Wiesbaden, S. 29-74. Servatius, H.-G. (1987): Internationales Technologie-Management zur Koordination von strategischen Allianzen und F&E-Netzwerken, in: Strategische Planung, o. Jg., Nr. 3, S. 217-243. Siebel, M. (2004): Fünf Trends als treibende Kräfte, Die Kunden formulieren ihre Anforderung an Unternehmenssoftware, in CeBIT 2004, Verlagsbeilage zur Frankfurter Allgemeine Zeitung, 65, S. 10. Sieber, P. (2003): Die Internet-Unterstützung virtueller Unternehmen, in: Sydow, J. (Hrsg.): Management von Netwerkorganisationen, Beiträge aus der Managementforschung, Wiesbaden, S. 179-214. Siebert, H. (2003): Ökonomische Analyse von Unternehmensnetzwerken, in: Sydow, J. (Hrsg.): Management von Netzwerkorganisationen - Beiträge aus der Managementforschung, Wiesbaden, S. 7-27. Snow, C. C./Miles, R. E./Coleman, J., Henry J. (1992): Managing 21st Century Network Organizations, in: Organizational Dynamics, 20. Jg., Nr. 3, S. 4-20. Sommerville, I. (2001): Software Engineering, München. Specht, D./Kahmann, J. (2000): Regelung kooperativer Tätigkeit im virtuellen Unternehmen, in: Albach, H./Specht, D./Wildemann, H. (Hrsg.): Virtuelle Unternehmen, Zeitschrift für Betriebswirtschaft, Ergänzungsheft 2/2000, Wiesbaden, S. 55-73. Stadlbauer, F./Hess, T. (2006): Integrationsmethoden für Unternehmensnetzwerke: eine fallstudienbasierte Suche nach Best Practices, in: Schelp, J./Winter, R./Frank, U./Rieger, B./Turowski, K. (Hrsg.): Integration, Informationslogistik und Architektur, Proceedings der DW2006, Friedrichshafen, S. 449-466. Stahlknecht, P./Hasenkamp, U. (1999): Einführung in die Wirtschaftsinformatik, Berlin. Stake, R. (1995): The Art Of Case Study Research, Thousand Oaks. Staudt, E./Toberg, M./Linné, H./Bock, J./Thielemann, F. (1992): Kooperationshandbuch: Ein Leitfaden für die Unternehmenspraxis, Stuttgart. Steffen, T. (2002): Modellierungsmethode zur Integration zwischenbetrieblicher Informationsflüsse, Berlin. Steinbock, H.-J. (1994): Potentiale der Informationstechnik: State-of-the-Art und Trends aus Anwendungssicht, Stuttgart. Steinbruch, K. (1978): Maßlos informiert, Die Enteignung unseres Denkens, München.

258

Literaturverzeichnis

Steven, M./Otterpohl, L. (2000): Virtuelle Unternehmen aus spieltheoretischer Sicht, in: Albach, H./Specht, D./Wildemann, H. (Hrsg.): Virtuelle Unternehmen, Zeitschrift für Betriebswirtschaft, Ergänzungsheft 2/2000, Wiesbaden, S. 177200. Stietz, O. (1995): Integrationsmanagement: dargestellt am Beispiel des Computer Integrated Manufacturing (CIM) in der deutschen Automobilindustrie, Frankfurt. Stuhldreier, F./Ellerkmann, F. (2000): Cooperate to compete - Ein Kooperationsgestaltungsleitfaden für den Großhandel im Produktionsverbindungshandel, Dortmund. Suchan, C./Schneider, J. (2006): Erweiterung einer Methodik zur Integration von Anwendungssystemen um Konzepte des Ubiquitous Computing, in: Lehner, F./Nösekabel, H./Kleinschmidt, P. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2006 - Tagungsband 2, Passau, S. 375-385. Sydow, J. (1992): Strategische Netzwerke, Evolution und Organisation, Wiesbaden. Sydow, J. (1995): Organisation von Netzwerken Strukturationstheoretische Analysen der Vermittlungspraxis in Versicherungsnetzwerken, Wiesbaden. Sydow, J. (1999): Quo Vadis Transaktionskostentheorie? - Wege, Irrwege, Auswege, in: Edeling, T./Jann, W./Wagner, D. (Hrsg.): Institutionenökonomie und Neuer Institutionalismus - Überlegungen zur Organisationstheorie, Opladen, S. 165176. Sydow, J. (2001): Zum Verhältnis von Netzwerken und Konzernen: Implikationen für das strategische Management, in: Ortmann, G./Sydow, J. (Hrsg.): Strategie und Strukturation - Strategisches Management von Unternehmen, Netzwerken und Konzernen, Wiesbaden, S. 271-298. Sydow, J. (2003): Management von Netzwerkorganisationen - Zum Stand der Forschung, in: Sydow, J. (Hrsg.): Management von Netzwerkorganisationen, Beiträge aus der Managementforschung, Wiesbaden, S. 293-354. Syring, A. (1993): Management innovativer Informationssysteme: Portfolio-Methodik zur Bewältigung der Komplexität des Übergangs, Göttingen. Tallon, P./Kauffman, R./Whinston, A./Zhu, K. (2002): Using Real Options Analysis for Evaluating Uncertain Investments in Information Technology: Insights from the ICIS 2001 Debate, in: Communications of the Association for Information Systems, 9. Jg., Nr. o., S. 136-167. Taudes, A./Feurstein, M./Mild, A. (2000): Options Analysis of Software Platform Decisions: A Case Study, in: MIS Quarterly, 24. Jg., Nr. 2, S. 227-243. Teubner, R. A. (1999): Organisation und Informationssystemgestaltung: theoretische Grundlagen und integrierte Methoden, Wiesbaden. Treuling, W. (1990): Formalismen versus Heuristik - Vorbereitung der Managemententscheidung, in: Information Management, 5. Jg., Nr. 4, S. 42-52. Tröndle, D. (1987): Kooperationsmanagement: Steuerung interaktioneller Prozesse bei Unternehmenskooperationen, Bergisch Gladbach. Tschandl, M. (2000): Phasenmodell der Entstehung eines virtuellen Unternehmens Initiierung, Akquisition und Kooperationsmanagement, in: io management, 69. Jg., Nr. 12, S. 76-85.

Literaturverzeichnis

259

Uebernickel, F./Bravo-Sànchez, C./Zarnekow, R./Brenner, W. (2006): Vorgehensmethodik zum IT-Produktengineering, in: Lehner, F./Nösekabel, H./Kleinschmidt, P. (Hrsg.): Multikonferenz Wirtschaftsinformatik 2006 - Tagungsband 2, Passau, S. 199-210. Voigtmann, P./Zeller, T. (2002): Enterprise Application Integration und B2B Integration im Kontext von Electronic Business und Elektronischen Marktplätzen, Teil I: Grundlagen und Anforderungen, Erlangen-Nürnberg. Voigtmann, P./Zeller, T. (2003): Beiträge zur Integrationsproblematik im Kontext von Electronic Business und Elektronischen Marktplätzen, Wirtschaftsinformatik 2003. von Stengel, R. (1999): Gestaltung von Wertschöpfungsnetzwerken, Wiesbaden. Voß, S./Gutenschwager, K. (2001): Informationsmanagement, Berlin. Wang, Y./Ahmed, P./Worall, L. (2004): Understanding inter-firm network: a theoretical review, in: International Journal of Management Concepts and Philosophy, 1. Jg., Nr. 1, S. 73-98. Ward, J. (1988): Information Systems and Technology Application Portfolio Management - an Assessment of Matrix-Based Analysis, in: Journal of Information Technology, 3. Jg., Nr. 3, S. 205-215. Ward, J./Griffiths, P./Whitmore, P. (1990): Strategic Planning für Information Systems, Chichester. Weber, J. (2004): Einführung in das Controlling, 10. Auflage, Stuttgart. Wild, M./Herges, S. (2000): Total Cost of Ownership (TCO) - Ein Überblick, Lehrstuhl für Allgemeine BWL und Wirtschaftsinformatik, Arbeitspapiere der Wirtschaftsinformatik Nr. 1/2000, Mainz. Wildemann, H. (1998): Entwicklungs-, Produktions- und Vertriebsnetzwerke in der Zulieferindustrie: Ergebnisse einer Delphiestudie, München. Willcocks, L. (2001): Evaluation the Outcomes of Information Systems Plans: Managing information technology evaluation - techniques and processes, in: Galliers, R./Leidner, D./Baker, B. (Hrsg.): Strategic Information Management: Challenges and Strategies in Managing Information Systems, Oxford, S. 271294. Williams, L. (1997): Planning and managing the information system - a manager's guide, in: Industrial Management & Data Systems, 97. Jg., Nr. 5, S. 187-191. Williamson, O. (1975): Markets and Hierarchies: Analysis and Antitrust Implications. A Study in the Economics of Internal Organization, New York. Windeler, A./Lutz, A./Wirth, C. (2000): Netzwerksteuerung durch Selektion - Die Produktion von Fernsehserien in Projektnetzwerken, in: Sydow, J./Windeler, A. (Hrsg.): Steuerung von Netzwerken, Opladen, S. 178-205. Winkeler, T./Raupach, E./Westphal, L. (2001): Enterprise Application Integration als Pflicht vor der Business-Kür, in: Information Management & Consulting, 16. Jg., Nr. 1, S. 7-16. Winter, R. (2000): Zur Positionierung des Data Warehousing in der betrieblichen Applikationsarchitektur, in: Schmidt, H. (Hrsg.): Proceedings der MobISFachtagung 2000, 11.-12. Oktober 2000, Universität Siegen, S. 23-40.

260

Literaturverzeichnis

Winter, R. (2006): Ein Modell zur Visualisierung der Anwendungslandschaft als Grundlage der Informationssystem-Architekturplanung, in: Schelp, J./Winter, R. (Hrsg.): Integrationsmanagement - Planung, Bewertung und Steuerung von Applikationslandschaften, Berlin, S. 1-29. Winter, R./Strauch, B. (2004): Information requirements engineering for data warehouse systems, in: Haddad, H. (Hrsg.): SAC '04: Proceedings of the 2004 ACM symposium on Applied computing, Nicosia, S. 1359-1365. Wittenberg, S. (2004): Gestaltung interner Märkte in Unternehmensnetzwerken - Organisationstheoretische Analyse und fachliche Konzeption einer ITWerkzeugunterstützung, Universität München, München. Wittmann, W. (1959): Unternehmung und unvollkommene Information: Unternehmerische Voraussicht - Ungewissheit und Planung, Köln und Opladen. WKWI (1994): Wissenschaftliche Kommission Wirtschaftsinformatik im Verband der Hochschullehrer für Betriebswirtschaft e.V.: Profil der Wirtschaftsinformatik, in: Wirtschaftsinformatik, 36. Jg., Nr. 1, S. 80-81. Wöhe, G. (2002): Einführung in die allgemeine Betriebswirtschaftslehre, 21., neubearbeitete Auflage, München. Wohlgemuth, O. (2002): Management netzwerkartiger Kooperationen, Instrumente für die unternehmensübergreifende Steuerung, Wiesbaden. Wohlgemuth, O./Hess, T. (2001): Kooperationen als Forschungsobjekt - eine quantitative Analyse. Arbeitsbereicht Nr.5/2000 der Abteilung für Wirtschaftsinformatik II der Universität Göttingen, Göttingen. Wolff, B./Neuburger, R. (1995): Zur theoretischen Begründung von Netzwerken aus der sicht der Neuen Institutionenökonomik, in: Jansen, D./Schubert, K. (Hrsg.): Netzwerke und Politikproduktion: Konzepte, Methoden und Perspektiven, Bochum, S. 74-94. Wortmann, J. (2001): Concurrent Requirements Engineering with a UML Subset based on Component Schema Relationships, Dissertation, Technische Universität Berlin, Berlin. Yin, R. (2003): Applications of Case Study Research, Thousand Oaks. Yusuf, Y./Gunasekaran, A./Abthorpe, M. (2004): Enterprise information systems project implementation: A case study of ERP in Rolls-Royce, in: International Journal of Production Economics, 87. Jg., Nr. 3, S. 251-266.