Entwicklung_eines_Vorgehensmodells_Nedbal_2013

Transcription

Eidesstattliche Erklärung
I
Entwicklung eines Vorgehensmodells für die
partizipative Einführung betrieblicher Integrationslösungen
Dissertation zur Erlangung des akademischen Grades
Dr. rer.soc.oec.
Doktoratsstudium der Sozial und Wirtschaftswissenschaften
Angefertigt am Institut für Anwendungsorientierte Wissensverarbeitung
Eingereicht von:
Mag. Dietmar Nedbal
Beurteilung:
Erstbetreuer: ao. Univ.-Prof. DI Dr. Wolfram Wöß
Zweitbetreuerin: ao. Univ.-Prof. Mag. Dr. Christine Strauß
Linz, Juni 2013
A-4040 Linz • Altenberger Straße 69 • Internet: http://www.jku.at • DVR 0093696
III
Ich erkläre an Eides statt, dass ich die vorliegende Dissertation selbstständig und
ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht
benutzt bzw. die wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich
gemacht habe.
Die vorliegende Dissertation ist mit dem elektronisch übermittelten Textdokument
identisch.
Dietmar Nedbal
Inhaltsverzeichnis
V
Inhaltsverzeichnis
1 Einleitung ........................................................................................................... 1 2 Handlungsbedarf und Forschungsmethodik .................................................. 6 2.1 Handlungsbedarf und forschungsleitende Fragestellungen ........................... 6 2.2 Thematische Einordnung und Forschungsmethodik .....................................12 2.2.1 Literaturrecherche ...................................................................................18 2.2.2 Explorative Studie ...................................................................................19 2.2.3 Fallstudien...............................................................................................20 2.2.4 Modellbildung und Konsolidierung .........................................................22 2.2.5 Durchführung von Pilotprojekten .............................................................23 2.2.6 Reflexion .................................................................................................23 2.3 3 Zusammenfassung .......................................................................................23 Grundlagen der betrieblichen Integration zur Erschließung des
Forschungskontextes ......................................................................................26 3.1 Begriffsbestimmung und –abgrenzung .........................................................27 3.2 Integrationsdimensionen: Technologie, Organisation und betriebliches
Umfeld als Rahmen für eine holistische Betrachtung....................................37 3.2.1 Arten und Formen der Integration ...........................................................37 3.2.2 Erklärungsansätze zur betrieblichen Integration: Verbreitung und
Akzeptanz von Technologie ....................................................................42 3.2.3 Einflussfaktoren auf die Entscheidung zur Nutzung von Systemen und
Technologien zur betrieblichen Integration .............................................48 3.3 Relevante konzeptuelle Ansätze und Rahmenwerke auf unterschiedlichen
Ebenen im Detail...........................................................................................58 3.3.1 Das Dreiebenenmodell des Business Networking ..................................59 3.3.2 Integration heterogener Informationssysteme .........................................61 3.3.3 „EAI Integration Layers” ..........................................................................62 3.3.4 „B2B Reference Framework“ ..................................................................63 3.3.5 „Collaborative Business Process Management“ .....................................66 3.3.6 Rahmenwerk zur IOS-Adoption ..............................................................67 3.3.7 Die „Integrated Vision for Electronic B2B-Collaboration”.........................68 3.3.8 Das „Three-level framework for Modeling B2B Applications” ..................71 3.3.9 Der „Social Collaboration Layer“ .............................................................72 3.4 Integrationsebenen: Vergleichende Betrachtung der Ebenen konzeptueller
Ansätze und Rahmenwerke ..........................................................................73 3.4.1 Integration auf Ebene der Daten .............................................................76 VI
Inhaltsverzeichnis
3.4.2 Integration auf Ebene der betrieblichen Informationssysteme ................80 3.4.3 Einsatz von dedizierter Software als „Middleware“ zur Integration..........82 3.4.4 Integration auf der sozialen Ebene .........................................................84 3.4.5 Integration auf Ebene der Prozesse und Services ..................................87 3.5 4 Zusammenfassung .......................................................................................90 Explorative Studie zur Bestimmung der Praxisrelevanz...............................94 4.1 Methodik der Studie ......................................................................................95 4.1.1 Ziel der Befragung ..................................................................................95 4.1.2 Themenkatalog .......................................................................................96 4.1.3 Ablauf der Befragung ..............................................................................96 4.1.4 Auswertung der Ergebnisse ....................................................................97 4.2 Ausgewählte Ergebnisse der Befragung .......................................................98 4.2.1 Durchführung von elektronischem Datenaustausch ................................99 4.2.2 Strategische Orientierung .....................................................................100 4.2.3 Unternehmensinterne Know-How Träger ..............................................102 4.2.4 Bedarf an Outsourcing ..........................................................................103 4.2.5 Durchdringung von betrieblichen Informationssystemen ......................105 4.2.6 Standards zur betrieblichen Integration.................................................107 4.2.7 Ziele einer effektiven betrieblichen Integration ......................................108 4.3 5 Zusammenfassung .....................................................................................112 Vorgehensmodelle in der Literatur ...............................................................115 5.1 Begriffsbestimmung und –abgrenzung .......................................................116 5.2 Überblick und Klassifikation ........................................................................121 5.3 Relevante Vorgehensmodelle im Detail ......................................................124 5.3.1 Wasserfallmodell ...................................................................................124 5.3.2 Das klassische sequenzielle Phasenmodell der Softwareentwicklung ..125 5.3.3 Spiralmodell ..........................................................................................127 5.3.4 Das Prototyping-orientierte Prozessmodell ...........................................127 5.3.5 Phasenmodell in der Systemplanung ....................................................128 5.3.6 Vorgehensmodell der Systementwicklung nach Stahlknecht und
Hasenkamp ...........................................................................................129 5.3.7 Vorgehensmodell der Systementwicklung nach Schwarze ...................130 5.3.8 oose Engineering Process (OEP) .........................................................130 5.3.9 Accelerated SAP (ASAP) ......................................................................131 5.3.10 Methodik zur Service-orientierten Entwicklung .....................................133 5.3.11 Projektablauf beim Business Engineering .............................................134 Inhaltsverzeichnis
VII
5.3.12 Vorgehensweise im Business Networking ............................................135 5.3.13 ISM-Vorgehensmodell...........................................................................137 6 5.4 Synoptischer Vergleich ausgewählter Vorgehensmodelle ..........................138 5.5 Anforderungen an das Vorgehensmodell....................................................141 5.6 Zusammenfassung .....................................................................................144 Fallstudien zur betrieblichen Integration .....................................................146 6.1 Methodik und Überblick ..............................................................................147 6.1.1 Unternehmen für Fallstudie auswählen .................................................148 6.1.2 Experteninterviews durchführen ............................................................149 6.1.3 Forschungsfall erstellen ........................................................................150 6.2 Fallstudie 1: Betriebliche Integration durch Outsourcing von
Geschäftsprozessen (Büroprofi) .................................................................150 6.2.1 Unternehmensdarstellung der beteiligten Unternehmen .......................151 6.2.2 Vorgehensweise bei der Integration .....................................................152 6.2.3 Diskussion der Integrationslösung ........................................................154 6.3 Fallstudie 2: Elektronische Rechnungslegung (GRZ) .................................156 6.3.1 Unternehmensdarstellung der beteiligten Unternehmen .......................156 6.3.2 Vorgehensweise bei der Integration ......................................................157 6.3.3 Diskussion der Integrationslösung ........................................................159 6.4 Fallstudie 3: Middleware zur Integration (Schuller) .....................................162 6.4.1 Unternehmensdarstellung der beteiligten Unternehmen .......................162 6.4.2 Vorgehensweise bei der Integration ......................................................163 6.4.3 Diskussion der Integrationslösung ........................................................165 6.5 Fallstudienvergleich ....................................................................................167 6.5.1 Vergleich im Bezugsrahmen .................................................................167 6.5.2 Vergleich der Vorgehensweise bei der Integration und Modellbildung ..170 6.6 7 Zusammenfassung .....................................................................................172 Konsolidiertes Vorgehensmodell zur betrieblichen Integration ................175 7.1 Überblick über das Vorgehensmodell .........................................................176 7.2 Rollen im Vorgehensmodell ........................................................................177 7.3 Beschreibung der Phasen ...........................................................................178 7.3.1 Orientierung (Phase 1) ..........................................................................178 7.3.2 Analyse (Phase 2) .................................................................................181 7.3.3 Design (Phase 3) ..................................................................................185 7.3.4 Realisierung (Phase 4)..........................................................................188 7.3.5 Betrieb (Phase 5) ..................................................................................189 VIII
Inhaltsverzeichnis
7.4 8 Zusammenfassung .....................................................................................193 Anwendung des Vorgehensmodells in der Praxis ......................................198 8.1 Überblick über Pilotprojekte ........................................................................199 8.2 Pilotprojekt 1: Standortübergreifende Integration bei Teufelberger .............200 8.2.1 Unternehmensdarstellung .....................................................................200 8.2.2 Vorgehensweise bei der Projektabwicklung ..........................................202 8.3 Pilotprojekt 2: Lieferanten- und Kundenintegration bei NKE .......................211 8.3.1 Unternehmensdarstellung .....................................................................211 8.3.2 Vorgehensweise bei der Projektabwicklung ..........................................212 8.4 Pilotprojekt 3: Standortübergreifende Innovationsnetzwerke bei Fronius ...218 8.4.1 Unternehmensdarstellung .....................................................................218 8.4.2 Vorgehensweise bei der Projektabwicklung ..........................................219 8.5 9 Zusammenfassung .....................................................................................225 Reflexion .........................................................................................................228 9.1 Zusammenfassung der zentralen Ergebnisse .............................................228 9.2 Kritische Würdigung ....................................................................................231 9.3 Ausblick ......................................................................................................234 Literaturverzeichnis ..............................................................................................239 Anhänge .................................................................................................................260 Anhang A: Fragebogen zur explorativen Studie ...................................................260 Anhang B: Tabellarische Auswertungsergebnisse ...............................................270 Anhang C: Struktur für Fallstudien mit Fragen für Interviews ...............................278 Anhang D: Interviewleitfaden für die Workshops in den Pilotprojekten ................280 Anhang E: Fragebogen zu Erfolgsfaktoren bei Teufelberger ...............................283 Anhang F: RACI-Matrix für das Vorgehensmodell ...............................................285 Abkürzungsverzeichnis ........................................................................................286 Lebenslauf............................................................................................................289 Abbildungsverzeichnis
IX
Abbildungsverzeichnis
Abbildung 1: Aufbau von Kapitel 2 (eigene Darstellung) ............................................ 6 Abbildung 2: Die Forschungsmethodik als idealisierte S-förmige Wissenskurve im
zeitlichen Verlauf (Malhotra und Grover), Zuordnung zu den vier Phasen
gestaltungsorientierter Forschung nach Österle et al. und Methoden-Mix der
gegenständlichen Arbeit. ...................................................................................17 Abbildung 3: Aufbau der Arbeit mit Zuordnung zu den in den Kapiteln zu
beantwortenden Forschungsfragen (FS1 bis FS6) und den vier Phasen der
Forschungsmethodik (eigene Darstellung) ........................................................24 Abbildung 4: Aufbau von Kapitel 3 (eigene Darstellung) ...........................................26 Abbildung 5: Eignung von IOS-Arten zur Unterstützung von Partnerschaften ...........40 Abbildung 6: Zusammenhang zwischen Integration und Kollaboration .....................42 Abbildung 7: Prozess zum Aufbau von Partnerschaften ............................................44 Abbildung 8: Vernetzung auf den drei Ebenen des Business Engineering im Business
Networking ........................................................................................................59 Abbildung 9: Integration heterogener Informationssysteme zur Unterstützung der
Prozesse ...........................................................................................................62 Abbildung 10: "EAI Integration Layers" ......................................................................63 Abbildung 11: B2B Reference Framework ................................................................64 Abbildung 12: Rahmenwerk für das kollaborative Geschäftsprozessmanagement ...67 Abbildung 13: Rahmenwerk zur IOS-Adoption in Wertschöpfungsketten ..................68 Abbildung 14: Integrated Vision for Electronic B2B-Collaboration .............................69 Abbildung 15: Das “Three-level framework for Modeling B2B Applications” ..............71 Abbildung 16: „Social Collaboration Layer“................................................................73 Abbildung 17: Vergleich konzeptueller Ansätze zur betrieblichen Integration (eigene
Darstellung) .......................................................................................................74 Abbildung 18: Einsatzbereiche von E-Business Standards .......................................79 Abbildung 19: Übersicht über betriebliche Informationssysteme im Unternehmen ....81 Abbildung 20: Grundlegende Konzepte für Enterprise 2.0 und Beispiele von
Technologien und Werkzeugen.........................................................................85 Abbildung 21: Zuordnung von Enterprise 2.0 Werkzeugen zu den SLATESCharakteristika (eigene Darstellung) .................................................................86 Abbildung 22: Aufbau von Kapitel 4 (eigene Darstellung) .........................................94 Abbildung 23: Auswertung der Durchführung von elektronischem Datenaustausch
(dh. eine betriebliche Integration) nach Unternehmensgröße (eigene
Darstellung) .....................................................................................................100 Abbildung 24: Auswertung über unterschiedliche Strategien bzw. Richtlinien im ITBereich (Mehrfachnennung möglich) (eigene Darstellung) .............................101 Abbildung 25: Vorhandensein eines IT Verantwortlichen in den Unternehmen (eigene
Darstellung) .....................................................................................................103 X
Abbildungsverzeichnis
Abbildung 26: Outsourcing unterschiedlicher Geschäftsbereiche (Mehrfachnennung
möglich) (eigene Darstellung) .........................................................................104 Abbildung 27: Einsatz unterschiedlicher betrieblicher Informationssysteme,
Anwendungen und Lösungen im Unternehmen (Mehrfachnennung möglich)
(eigene Darstellung) ........................................................................................106 Abbildung 28: Bekanntheit und Einsatz von Standards Klassifikationen zur
betrieblichen Integration in Unternehmen (eigene Darstellung) ......................108 Abbildung 29: Anforderungen/Ziele an effektive betriebliche Integration. Vergleich
von Unternehmen mit noch nicht durchgeführter („Nein“ / „Geplant“) und bereits
abgeschlossener („Ja“) Integration (eigene Darstellung) ................................110 Abbildung 30: Zielerreichung bei bereits erfolgter Integration (eigene Darstellung) 111 Abbildung 31: Aufbau von Kapitel 5 (eigene Darstellung) .......................................115 Abbildung 32: Ordnungsschema für Vorgehensmodelle der Gesellschaft für
Informatik ........................................................................................................119 Abbildung 33: Wasserfallmodell von Boehm nach Royce .......................................125 Abbildung 34: Sequenzielles Phasenmodell ............................................................126 Abbildung 35: Prototyping-orientiertes Life-Cycle-Modell nach Pomberger .............128 Abbildung 36: Vorgehensmodell der Systementwicklung nach Stahlknecht und
Hasenkamp .....................................................................................................129 Abbildung 37: Vorgehensmodell der Systementwicklung nach Schwarze ...............130 Abbildung 38: OEP Phasenmodell ..........................................................................131 Abbildung 39: Die Phasen der Methodik „Accelerated SAP“ ...................................132 Abbildung 40: Phasen im Service-orientierten Entwurf und Implementierung .........134 Abbildung 41: Revolution und Evolution im Business Engineering ..........................135 Abbildung 42: Vorgehen im Business Networking ...................................................136 Abbildung 43: ISM-Vorgehensmodell ......................................................................137 Abbildung 44: Vergleich ausgewählter Vorgehensmodelle (eigene Darstellung).....139 Abbildung 45: Aufbau von Kapitel 6 (eigene Darstellung) .......................................146 Abbildung 46: Wertschöpfung nach Outsourcing der Prozesse (eigene Darstellung)
........................................................................................................................154 Abbildung 47: Überblick über den Waren- und Informationsfluss der
Integrationslösung der Fallstudie „Büroprofi“ (eigene Darstellung) .................155 Abbildung 48: Überblick über die Integrationslösung mit „flexdoc“ (eigene
Darstellung) .....................................................................................................160 Abbildung 49: Kostenfunktion der bisherigen Lösung und mit „flexdoc“ (eigene
Darstellung) .....................................................................................................161 Abbildung 50: Überblick über die Integrationslösung der Fallstudie „Schuller“ (eigene
Darstellung) .....................................................................................................166 Abbildung 51: Einbettung der Fallstudien in den Bezugsrahmen (eigene Darstellung)
........................................................................................................................168 Abbildung 52: Vorgehensweise bei der Integration in den Fallstudien (eigene
Darstellung) .....................................................................................................171 Abbildungsverzeichnis
XI
Abbildung 53: Aufbau von Kapitel 7 (eigene Darstellung) .......................................175 Abbildung 54: Überblick über das konsolidierte Vorgehensmodell (eigene
Darstellung) .....................................................................................................176 Abbildung 55: Aufbau von Kapitel 8 (eigene Darstellung) .......................................198 Abbildung 56: Auswertung der Erfolgsfaktoren nach Prioritäts-Leistungs-Quadranten
(eigene Darstellung) ........................................................................................205 Abbildung 57: Design der „IdeaBoard“-Funktionalität (eigene Darstellung) .............206 Abbildung 58: Heuristische Evaluierung - Auswertung des Gesamteindrucks (eigene
Darstellung) .....................................................................................................208 Abbildung 59: Eye-Tracking Analyse: Benötigte Zeit zum Auffinden (“Time to first
Fixation“) (eigene Darstellung) ........................................................................209 Abbildung 60: Scan-Pfade zum „I-Like-It“ Tag vor der Schulung (links) und nach der
Schulung (rechts) (eigene Darstellung) ...........................................................210 Abbildung 61: Bestellanfrage Ist-Prozess zwischen NKE und Lieferant DHK (eigene
Darstellung) .....................................................................................................215 Abbildung 62: Vorgehen beim Design der Lösung (Ausschnitt) (eigene Darstellung)
........................................................................................................................223 Abbildung 63: Konzeptionelles Design der Innovationsnetzwerke (eigene
Darstellung) .....................................................................................................224 Abbildung 64: Einbettung der Pilotprojekte in den Bezugsrahmen (eigene
Darstellung) .....................................................................................................226 XII
Tabellenverzeichnis
Tabellenverzeichnis
Tabelle 1: Entwicklungsphasen von Integrationstechnologien...................................29 Tabelle 2: Unterschiedliche Ausprägungen bei der Verwendung des Begriffs
„Integration“ .......................................................................................................30 Tabelle 3: Einflussfaktoren zur Nutzung von neuen Systemen und Technologien ....49 Tabelle 4: Einflussfaktoren der Integrationsdimension „Technologie“ .......................51 Tabelle 5: Einflussfaktoren der Integrationsdimension „Organisation“
(innerbetriebliche Faktoren) ..............................................................................53 Tabelle 6: Einflussfaktoren der Integrationsdimension „Organisation“ (über- und
zwischenbetriebliche Faktoren) .........................................................................55 Tabelle 7: Einflussfaktoren der Integrationsdimension „Betriebliches Umfeld
(Rahmenbedingungen)“ ....................................................................................57 Tabelle 8: Befunde der Hypothesenprüfung im Überblick .......................................114 Tabelle 9: Einteilung von Vorgehensmodellen nach Gestaltungsstrategien der
Systementwicklung .........................................................................................121 Tabelle 10: Anforderungen an das Vorgehensmodell..............................................142 Tabelle 11: Eckdaten der Fallstudien ......................................................................147 Tabelle 12: Einordnung des Vorgehensmodells nach Gestaltungsstrategien der
Systementwicklung .........................................................................................194 Tabelle 13: Eckdaten der Pilotprojekte ....................................................................199 Tabelle 14: Punktevergabe in den Workshops (WS) bei Fronius ............................221 Tabelle 15: Führen Sie bereits überbetrieblichen elektronischen Datenaustausch (dh.
eine betriebliche Integration) mit Geschäftspartnern durch? ...........................270 Tabelle 16: Korrelation Unternehmensgröße und überbetrieblicher elektronischer
Datenaustausch. .............................................................................................270 Tabelle 17: Welche der folgenden Strategien/Richtlinien im IKT-Bereich gibt es in
Ihrem Unternehmen? (Mehrfachnennung möglich) .........................................270 Tabelle 18: Korrelation Unternehmensgröße und Strategien/Richtlinien im IKTBereich ............................................................................................................271 Tabelle 19: Ist in Ihrem Unternehmen ein IT Verantwortlicher vorhanden? .............271 Tabelle 20: Korrelation Unternehmensgröße und IT Verantwortlicher .....................272 Tabelle 21: Welche der folgenden Geschäftsbereiche haben Sie outgesourct?
(Mehrfachnennung möglich) ...........................................................................272 Tabelle 22: Korrelation Unternehmensgröße und Outsourcing von
Geschäftsbereichen. .......................................................................................272 Tabelle 23: Welche der folgenden Anwendungen/Lösungen werden in ihrem
Unternehmen eingesetzt? ...............................................................................273 Tabelle 24: Korrelation Unternehmensgröße und eingesetzte E-Business
Anwendungen. ................................................................................................274 Tabellenverzeichnis
XIII
Tabelle 25: Welche der folgenden E-Business Standards/Klassifikationen kennen Sie
bzw. sind in Ihrem Unternehmen im Einsatz? .................................................275 Tabelle 26: Korrelation Unternehmensgröße und E-Business
Standards/Klassifikationen ..............................................................................275 Tabelle 27: Was wären/sind Ihrer Meinung nach die Anforderungen an eine effektive
betriebliche Integration? („Nein” oder „Geplant”); Was wollten Sie mit der
betrieblichen Integration erreichen? („Ja“) ......................................................276 Tabelle 28: Wurden die definierten Ziele der Integration erreicht? ..........................277 Tabelle 29: Zuordnung von Rollen zu Aktivitäten (RACI-Matrix)..............................285 XIV
Zusammenfassung
Zusammenfassung
In den letzten Jahren haben vor allem schnell zu etablierende Kooperationen zwischen Unternehmen stark an Bedeutung gewonnen. Eine Optimierung von innerbetrieblichen Geschäftsprozessen und Abläufen ist ebenso zur notwendigen Antwort
geworden wie das Bereitstellen von digitalen Geschäftsdokumenten oder die Nutzung von Services über das Internet, um in der globalisierten Wirtschaft wettbewerbsfähig zu bleiben.
Um diese Veränderungen, also die Einführung von Konzepten und Technologien zur
inner-, über- und zwischenbetrieblichen Integration, systematisch und effektiv durchzuführen, wird eine entsprechend strukturierte Vorgehensweise benötigt. Da die
derzeitige Unternehmenspraxis oftmals nicht auf eine methodische, ganzheitliche
sowie partizipative Betrachtung betrieblicher Integration abzielt, müssen Unternehmen hier Effizienzverluste in Kauf nehmen. Das primäre Ziel dieser Arbeit ist daher
die Konstruktion eines wissenschaftlich fundierten Vorgehensmodells zur Einführung
von betrieblichen Integrationslösungen, das den Anforderungen gängiger Unternehmenspraxis entspricht.
Zur Erreichung dieses Zieles beschreibt die vorliegende Arbeit zunächst den hierzu
notwendigen Handlungsbedarf, leitet davon wissenschaftliche Forschungsfragen ab
und hinterlegt diese mit einer geeigneten Forschungsmethodik. Danach werden die
Grundlagen der betrieblichen Integration für die gegenständliche Arbeit aus der
Literatur erarbeitet und darauf aufbauend die Ergebnisse einer empirischen Voruntersuchung diskutiert. Daran anschließend wird auf Vorgehensmodelle in der Literatur eingegangen, vorhandene Modelle werden verglichen und die Anforderungen an
das zu erstellende Vorgehensmodell werden abgeleitet. Zur Ermittlung der Anforderungen aus der Praxis werden erprobte Integrationslösungen in Form von Fallstudien
erhoben und einem Vergleich unterzogen. Zusätzlich wird das Vorgehensmodell in
drei Pilotprojekten angewendet und die Erkenntnisse daraus fließen wiederum in ein
nunmehr konsolidiertes Vorgehensmodell zur betrieblichen Integration zurück. Die
Arbeit schließt mit einer Zusammenfassung und kritischen Betrachtung der zentralen
Ergebnisse und einem Ausblick auf weitere mögliche Forschungstätigkeiten.
Schlagwörter
Vorgehensmodell, Betriebliche Integration, Integrationsebenen, Integrationsdimensionen, Integrationskonzepte
Abstract
XV
Abstract
In recent years, fast and effective cooperation to be established between organizations have become increasingly important. It is an optimization of internal business
processes as well as providing digital business documents for partners or the use of
services over the Internet that has become necessary in order to stay competitive in
the globalized economy.
As this integration may include multiple levels of integration (like data, application,
business process, etc.) at the same time, they are complex and multi-disciplinary by
nature. To carry out the changes involved in the introduction of concepts and technologies for intra- and inter-enterprise integration systematically and effectively,
organizations have the need for a properly planned, methodological approach. To
guide organizations in that process this thesis introduces a process model for business integration.
To achieve this goal, the thesis first describes the need for action in detail. The
research questions are deduced and an appropriate research methodology is designed. After that, the fundamentals of business integration for the present work are
developed from literature and preliminary results from an initial exploratory study are
discussed. Following this, a thematic analysis focusing on process models in scientific literature is presented, and the requirements for the process model to be developed are derived. The methodology also comprises case studies conducted to refine
and prove the practical applicability of the proposed process model. In addition, the
model gets evaluated in three pilot projects and the resulting conclusions are incorporated into it. The process model is finally consolidated using the results from
scientific literature and practice. The work concludes with a summary and critical
analysis of the key results and an outlook on possible further research.
Keywords
Process Model, Business Integration, Integration Levels, Integration Dimensions,
Integration Concepts
XVI
Vorwort
Vorwort
Die vorliegende Dissertation entstand während meiner beruflichen Tätigkeit als
wissenschaftlicher Mitarbeiter an der Fachhochschule Oberösterreich. Als Mitarbeiter
des Forschungsschwerpunkts „Digital Business“ durfte ich an mehreren Forschungsund Industrieprojekten mitwirken, was durch die Verschränkung von Praxis und
Forschung in hohem Ausmaß die vorliegende Arbeit inspiriert hat. So hatte ich im
Rahmen dieser Tätigkeit die Gelegenheit, die Arbeit in mehr als fünf Jahren in drei
Forschungsprojekten zu entwickeln, mehrere Pilotprojekte durchzuführen und meine
Ansätze auf internationalen Konferenzen mit einem Fachpublikum zu diskutieren.
Das Forschungsprojekt GuideBIS1 setzte in den Jahren 2007 bis 2009 den Rahmen
für die gegenständliche Arbeit. Erste Publikationen wurden veröffentlicht, eine explorative Studie durchgeführt und Fallstudien erhoben. Als Weiterführung der Arbeiten
aus GuideBIS konnte im Jahr 2009 mit dem Forschungsprojekt SCIM 2.02 begonnen
werden. In diesem richtungsweisenden Projekt erfolgte die weitere Vertiefung im
Themengebiet und Pilotprojekte starteten aus der Folge von SCIM 2.0 heraus. In den
Jahren 2010 bis 2012 hat das Forschungsprojekt 4EMOBILITY3 wesentlich zur
wissenschaftlichen Fundierung und am Schreiben der Dissertation selbst beigetragen, was die vorliegende Arbeit erst ermöglicht hat.
Forschung ist jedoch nie die Arbeit eines einzelnen. Zahlreiche Personen in meinem
beruflichen und privaten Umfeld haben entscheidend zum Gelingen der Arbeit beigetragen. Mein Dank gilt allen, die mich unterstützten.
1
“GuideBIS - Guidance Model for Business Integration Solutions” war ein FH OÖ basisfinanziertes
Forschungsprojekt von 2007-2009.
2
“SCIM 2.0 - Effektives Supply Chain Information Management in Wertschöpfungsnetzwerken mittels
Enterprise 2.0“ wurde von 2009-2012 im Rahmen des Programms „COIN – Aufbau“ gefördert vom
BMVIT/BMWFJ (Projekt-Nr. 821003).
3
Das Projekt 4EMOBILITY wurde im Rahmen des EU-Programms
„Regionale Wettbewerbsfähigkeit OÖ 2007-2013 (Regio 13)“ aus Mitteln
des Europäischen Fonds für Regionale Entwicklung (EFRE) sowie aus
Landesmitteln gefördert.
Einleitung
1
1 Einleitung
Befragt man Entscheidungsträger in Unternehmen, was eine „betriebliche Integration“ für sie bedeutet, kann man unterschiedliche Antworten erwarten. Für ein Unternehmen ist es der elektronische Austausch von Geschäftsdokumenten wie Bestellungen, Lieferscheinen und Rechnungen. Dabei wird das unternehmensinterne
Informationssystem auf technischer Ebene mit Kunden und Lieferanten integriert und
der gesamte Prozess von einer Bestellung bis zur Abrechnung medienbruchfrei
gestaltet. Ein anderes Unternehmen versteht unter Integration die Einführung von
elektronischer Rechnungslegung auf einer Software-as-a-Service (SaaS) Basis. Das
Service wird dabei als Druckertreiber in das ERP-System integriert und so der Fakturierungsprozess ausgelagert. Ein drittes Unternehmen wird durch Integration die
Vernetzung mehrerer Abteilungen und Standorte heben und damit den Informationsaustausch verbessern, Wissen generieren und Innovationen fördern. Dafür ist neben
der technologischen Fähigkeit zur Integration vor allem die Bereitschaft zur Informationsbereitstellung und -nutzung der eigenen Mitarbeiter in den Abteilungen notwendig. Diese drei Beispiele zeigen, dass je nach Ziel der Integration spezielle Technologien benötigt werden und dabei viele Personen in ihren Rollen als Mitarbeiter,
Kunden, Lieferanten, usw. involviert sind4.
Fakt ist: Aufgrund der Globalisierung und zunehmenden Technologisierung der
Waren- und Informationsströme haben vor allem effektive und schnell zu etablierende Kooperationen in den letzten Jahren stark an Bedeutung gewonnen5. Eine Integration und Optimierung von inner-, über- und zwischenbetrieblichen Geschäftsprozessen ist zur notwendigen Antwort für nachhaltigen wirtschaftlichen Erfolg geworden6. Das Internet mit seinen technologischen Innovationen ermöglichte den
Durchbruch von neuen Arten, Formen und Möglichkeiten zur Interaktion, Kooperation
und Kollaboration7. So existieren heute zahlreiche Werkzeuge, Konzepte, Technologien und Standards zur Zusammenarbeit und Abstimmung in und zwischen Unternehmen, die mit variierendem Erfolg in der Praxis Einsatz finden8. Beispiele hierfür
sind etwa der EDI-Nachrichtenstandard UN/EDIFACT, Web Services und serviceorientierte Integration von betrieblichen Informationssystemen, Web 2.0 Technologien
und Konzepte zum Informationsaustausch, oder Integrationsplattformen und Middle-
4
Die Beispiele sind aus der gegenständlichen Arbeit entnommen und werden, neben weiteren Praxisbeispielen, in den Fallstudien (Kapitel 6) bzw. Pilotprojekten (Kapitel 8) detailliert behandelt.
5
Vgl. Becker et al. (2008, S. 813)
6
Vgl. Legner (2009, S. 2762); Adam et al. (2004, S. 537); Eckert et al. (2005, S. 1463); Furdík et al.
(2009, S. 96); Lebender et al. (2003, S. 9); Yao et al. (2011, S. 299)
7
Vgl. Themistocleous und Irani (2003, S. 1973); Legner (2009, S. 2762); Hu und Grefen (2002, S.
557); Wölfle (2006, S. 17)
8
Vgl. Themistocleous und Irani (2003, S. 1974)
2
Einleitung
ware-Lösungen. Die Auswahl und Implementierung derartiger Technologien wird
aber oft auf Basis lokaler Optima getroffen, auf die Berücksichtigung maßgeblicher
Anforderung und auf eine holistisch orientierte Vorgehensweise zur Umsetzung wird
verzichtet. In der Praxis sind daher eine Vielzahl an pragmatisch orientierten, proprietären Lösungen im Einsatz, die auf die entsprechende Zielgruppe angepasst sind9.
Auch äußere Rahmenbedingungen wie unterschiedliche Betriebsgrößen, technologische Voraussetzungen, mangelnde Prozessstabilität oder die Fähigkeit und Bereitschaft zum Informationsaustausch werden oftmals nur höchst anlassbezogen berücksichtigt. Dennoch hängt der Geschäftserfolg von modernen Unternehmen maßgeblich von deren Zusammenarbeit in der gesamten Wertschöpfungskette ab10.
Obwohl sich Firmen der strategischen Wichtigkeit dieser Partnerschaften immer
mehr bewusst werden11, sind es vor allem KMUs, die den Einsatz und die Chancen
von integrierten E-Business Lösungen nicht in gleichem Ausmaß wie Großunternehmen erkannt haben12.
Die klassischen Wettbewerbsstrategien Kostenführerschaft, Differenzierung und
Fokussierung nach Porter13 werden von modernen, erfolgreichen Unternehmen
heute vielfach bei der Bildung der Unternehmensstrategie um die gezielte Konzentration auf Kernkompetenzen erweitert14. State-of-the-art Informations- und Kommunikationstechnik (IKT) ermöglicht Unternehmen das Auslagern ganzer Geschäftsprozesse an Partner, bei gleichzeitiger effizienter und effektiver Nutzung der eigenen Ressourcen und Fähigkeiten im Umfeld der eigenen Kernkompetenzen15. Dadurch
entstehen langfristig orientierte Wertschöpfungsnetzwerke16, in denen sich einzelne
Unternehmen auf ihre Kernkompetenzen konzentrieren können und bedarfsorientiert
Waren und Informationen zu diesem Zweck austauschen, um einen gesamtheitlichen
Wettbewerbsvorteil zu erzielen17. Die Zusammenarbeit kann dabei von informellem
Informationsaustausch in Arbeitsgemeinschaften („Communities of Practice“)18 bis
zum
technologisierten
Güterund
Datenaustausch
in
Kunden9
Vgl. Schubert (2007, S. 271)
10
Vgl. Power (2005, S. 260)
11
Vgl. Bagchi et al. (2005, S. 275)
12
Vgl. Tan Ter Chian (2010, S. 1); Leimstoll und Schubert (2005, S. 984)
13
Vgl. Porter (2008)
14
Vgl. Schubert und Legner (2011, S. 250)
15
Vgl. Grefen et al. (2003, S. 488); Norta et al. (2006, S. 834)
16
Lieferanten-Abnehmer-Netzwerke werden auch als Supply Chains bezeichnet. Aufgrund ihrer
zumeist netzwerkartigen Struktur hat sich jedoch zunehmend der Begriff Supply Network bzw. Wertschöpfungsnetzwerk etabliert. Vgl. Teuteberg (2005, S. 4); Dufft und Tietz (2007, S. 3)
17
Vgl. Legner (2009, S. 2762); Iskanius und Kilpala (2006, S. 283); Hess (1998); Wu (2008, S. 241);
Ruile (2006, S. 131); Arend-Fuchs und Bielert (2009)
18
Wenger und Snyder (2000)
Einleitung
3
Lieferantenbeziehungen in ausgefeilten logistischen Lieferketten und parallel dazu
laufendem, digitalem Datenaustausch mit Standards wie UN/EDIFACT oder beispielsweise auf der Basis von XML19 reichen. Das Web ist zu einer beliebten Plattform für B2B Anwendungen geworden, mit dem Ziel, intra- und inter-organisationale
Geschäftsprozesse zu unterstützen20. Vor allem in B2B Märkten besteht durch diese
Formen der Zusammenarbeit die Gefahr des Abbaus von Vermittlerstellen. Aufgrund
von Redundanzen werden sie durch neue Intermediäre ausgetauscht oder schlichtweg nicht mehr benötigt. Intermediäre müssen neue Dienstleistungen anbieten, die
einen erheblichen Mehrwert für Kunden bzw. Lieferanten bieten, um am Markt zu
bestehen21. Chancen bieten auch hierfür neue Internettechnologien, die den Zugang
zu und die Nutzung von Informationen und Wissen vereinfachen.
Mit betrieblicher Integration wird „gewöhnlich kein Selbstzweck verfolgt, sondern
immer Mittel zum Zweck, meist Rationalisierung“22. Dies kann beispielsweise durch
eine Verbesserung des Informationsflusses zwischen den Beteiligten, eine Optimierung von Prozessen, die enge Integration mit Partnern, oder durch das Erzielen von
Netzwerkeffekten und „weichen“ Faktoren erreicht werden23. Die betriebliche Integration verdient daher nicht nur im über- und zwischenbetrieblichen Austausch zwischen
voneinander unabhängigen Unternehmen Beachtung. Durch die Verlagerung von
Produktionsstandorten in kostengünstigere Regionen, bei der Erschließung neuer
Vertriebsregionen, oder bei Übernahmen und Fusionen von Unternehmen gilt es
möglichst rasch auf die geänderte Unternehmenssituation zu reagieren und Synergien zu nutzen. Die betriebliche Integration ist folglich auch im innerbetrieblichen
Kontext wichtig24: Eine effiziente standortübergreifende Integration soll die Kommunikation über mehrere, verteilt agierende Abteilungen ermöglichen und Geschäftsprozesse vereinfachen. In der Literatur findet man häufig eine Unterscheidung zwischen
„B2B Integration“ für unternehmensübergreifende Integrationen und „Enterprise
Application Integration (EAI)“ für die innerbetriebliche Integration25. Doch nicht zuletzt
durch eine Anzahl produktreifer Implementierungen von Web Services und serviceorientierter Architektur (SOA) für die Integration verschwimmen die Unterschiede
zwischen unternehmensinterner und unternehmensübergreifender Integration zusehends. Eine flexibel gestaltete EAI-Lösung mit entsprechender Middleware kann
sowohl als Schnittstelle zu internen als auch externen Systemen verwendet wer-
19
Amer-Yahia und Kotidis (2004); Buxmann et al. (2002)
20
Brambilla et al. (2006, S. 361)
21
Walters (2008, S. 59)
22
Lehner et al. (1995, S. 133)
23
Schubert (2007, S. 268); Wölfle (2006, S. 9)
24
Campelo F. und Stucky (2004, S. 382)
25
Linthicum (2000, S. 16)
4
Einleitung
den26. Und bei der Verwendung von modernen Webtechnologien zum Informationsund Wissensaustausch spielt es technisch keine wesentliche Rolle, ob diese zur
besseren Kommunikation zwischen Abteilungen, oder zu Kunden und Lieferanten
verwendet werden27.
Neben der „klassischen“ webbasierten Integration mittels Web-EDI, Web Services
und deren Derivaten wird der Einsatz von Konzepten und Technologien der Web 2.0Generation in Unternehmen in Literatur und Praxis derzeit intensiv diskutiert. Immer
mehr Unternehmen experimentieren mit Blogs, Wikis, oder sozialen Netzwerken zum
inner-, über- und zwischenbetrieblichen Informations- und Wissensaustausch, oder
um Geschäftsprozesse abzubilden, die mehrere Personen, Abteilungen, Standorte
oder auch Kunden und Lieferanten inkludieren28. In der Literatur wird die Anwendung
dieser Konzepte und Technologien häufig mit dem Begriff „Enterprise 2.0“29 subsummiert. Gerade für KMUs bieten sich bei der Nutzung offener Enterprise 2.0
Konzepte und Technologien Chancen, sich durch den zielgerichteten Umgang mit
Wissen Wettbewerbsvorteile zu schaffen30. Die Nutzung ist dabei auch nicht mehr
nur High-Tech bzw. IT-Unternehmen vorbehalten; eine rasante Zunahme in allen
Branchen wird in den nächsten Jahren erwartet31. Wer diesen Wandel mitmacht bzw.
sich strategisch darauf vorbereitet hat, wird diesen mitgestalten, mitbestimmen und
daraus Nutzen ziehen können. Deshalb stellen Konzepte und Technologien des
„Enterprise 2.0“ mit ihren vielfältigen Möglichkeiten zur betrieblichen Integration für
die gegenständliche Arbeit eine sehr interessante und relevante Forschungsrichtung
dar, die es zu berücksichtigen gilt32.
Um diese Veränderungen, also die Einführung von Konzepten und Technologien zur
inner-, über- und zwischenbetrieblichen Integration, systematisch und effektiv durchzuführen, wird eine entsprechend strukturierte Vorgehensweise benötigt. Da die
derzeitige Unternehmenspraxis oftmals nicht auf eine methodische, ganzheitliche
sowie partizipative Betrachtung betrieblicher Integration abzielt, müssen Unternehmen hier Effizienzverluste in Kauf nehmen. Probleme beim Vorgehen während einer
Integration führen beispielsweise zu hohen Kosten und langen Einführungszeiten
und Unternehmen können in der Folge ihre Integrationsprojekte nicht oder nicht
26
Vgl. Aier (2006, S. 363); Themistocleous et al. (2002, S. 1089)
27
Vgl. Welker et al. (2008, S. 707–708)
28
Vgl. Dufft und Tietz (2007, S. 2)
29
Vgl. McAfee (2006b)
30
Vgl. Bibikas et al. (2008, S. 45f)
31
Vgl. Rohrbeck et al. (2009, S. 421); Gassmann und Enkel (2006, S. 132)
32
Vgl. Koch et al. (2007, S. 448)
Einleitung
5
wirtschaftlich umsetzen33. Ein methodisch fundierter und damit systematischer Ansatz zur Durchführung betrieblicher Integration fehlt. Das primäre Ziel dieser Arbeit ist
daher die Konstruktion eines Vorgehensmodells zur Einführung von betrieblichen Integrationslösungen, das den Anforderungen gängiger Unternehmenspraxis
entspricht.
Zur Erreichung dieses Zieles gliedert sich die vorliegende Arbeit in neun Kapitel.
Kapitel 2 beschreibt den hierzu notwendigen Handlungsbedarf, leitet davon die
Forschungsfragen ab und hinterlegt diese mit einer geeigneten Forschungsmethodik.
Danach werden die Grundlagen der betrieblichen Integration für die gegenständliche
Arbeit aus der Literatur erarbeitet (Kapitel 3). Darauf aufbauend werden die Ergebnisse einer Voruntersuchung in der Praxis diskutiert (Kapitel 4). Das Kapitel 5 befasst
sich mit den Grundlagen von Vorgehensmodellen, vergleicht vorhandene Modelle
und leitet die Anforderungen an das zu erstellende Vorgehensmodell zur betrieblichen Integration ab (Kapitel 5). In der Praxis erprobte Integrationslösungen werden in
Form von Fallstudien in Kapitel 6 beschrieben und einem Vergleich unterzogen.
Kapitel 7 stellt schließlich das konsolidierte Vorgehensmodell zur betrieblichen Integration vor. Die Anwendung des Vorgehensmodells in drei Pilotprojekten wird in
Kapitel 8 skizziert. Die Arbeit schließt mit einer Zusammenfassung und kritischen
Betrachtung der zentralen Ergebnisse und einem Ausblick auf weitere mögliche
Forschungstätigkeiten (Kapitel 9).
33
Vgl. Hinderer et al. (2003, S. 120)
6
Handlungsbedarf und Forschungsmethodik
2 Handlungsbedarf und Forschungsmethodik
Im folgenden Kapitel wird dargestellt, welche Herausforderungen sich bei der betrieblichen Integration ergeben, warum eine Strukturierung des Integrationsprozesses
benötigt wird, und dass dies aber in der gängigen Unternehmenspraxis meist nicht in
geeigneter Form umgesetzt ist. Basierend auf diesem Handlungsbedarf werden die
zu Grunde liegenden wissenschaftlichen Fragestellungen abgeleitet (Kapitel 2.1).
Kapitel 2.2 beschreibt die thematische Einordnung sowie die Forschungsmethodik
zur Beantwortung dieser Fragestellungen. Zum Abschluss wird in Kapitel 2.3 zusammenfassend der weitere Aufbau der Arbeit mit den wissenschaftlichen Fragestellungen hinterlegt und dargestellt. Abbildung 1 zeigt den Aufbau dieses Kapitels im
Überblick.
Abbildung 1: Aufbau von Kapitel 2 (eigene Darstellung)
2.1 Handlungsbedarf und forschungsleitende Fragestellungen
Aus den eingangs skizzierten Praxisbeispielen und Ansätzen betrieblicher Integration
wird evident, dass kooperative Integrationsprojekte in der betrieblichen Praxis noch
immer eine große Herausforderung darstellen34. Bestehende Lösungen sind oftmals
nicht methodisch fundiert und zielen nicht auf eine ganzheitliche Betrachtung ab,
wodurch Unternehmen Effizienzverluste in Kauf nehmen müssen. Unternehmen sind
34
Vgl. Trappey et al. (2007, S. 1222)
7
teilweise nicht in der Lage, diese Integrationsprojekte umzusetzen, was zum Scheitern des Projekts führen kann. Um dies zu verhindern, muss einem Integrationsprojekt eine geeignete Struktur zugrunde gelegt werden.
Als Hintergrund des erhöhten Strukturbedarfs sind veränderte Kundenerwartungen,
die gestiegene Marktdynamik und die Dynamik im Wettbewerb der vergangenen
Jahren zu nennen35: Kunden erwarten sich höhere Qualität, niedrigere Preise und
kürzere Lieferzeiten. Die Marktsituation veränderte sich aufgrund fallender Grenzen,
einheitlicher Währungen, Outsourcing, zuverlässigere Informationssysteme und
effizientere Logistiksysteme. Erfahrungen aus der Vergangenheit können immer
weniger zur Prognose der Zukunft verwendet werden. Diese Entwicklung wurde
durch die Liberalisierung des internationalen Waren- und Kapitalverkehrs verstärkt.
Neue Märkte erhöhen die Komplexität der globalen Wettbewerbssituation und der
kundenseitige Kosten-, Qualitäts- und Margendruck belastet die Unternehmen weltweit. Diese müssen innovative Produkte in immer kürzerer Zeit entwickeln und neue
Services kundenindividuell anbieten können. Eine Strukturierung der Abläufe im
komplexen Umfeld wird nötig, um diese Komplexität beherrschbar zu machen.
Komplexität bezeichnet allgemein die „Eigenschaft eines Systems, die durch die
Anzahl seiner Elemente und durch die Anzahl der Beziehungen zwischen den Elementen (Beziehungsreichtum) gekennzeichnet ist.“36 Maßgeblich verantwortlich für
die wachsende Komplexität ist demnach der zunehmende Beziehungsreichtum der
Unternehmen und den Beziehungen mit ihrer Umwelt37. Folgende Schnittstellen
gelten als Herausforderungen38:

Kunde und Unternehmen: Mit der Internationalisierung und Globalisierung des
Marktes wächst auch der Anteil internationaler Kunden.

Unternehmen und Lieferant: Die zunehmende Konzentration auf Kernkompetenzen lässt den Leistungsumfang eines Unternehmens geringer werden.
Durch diese Spezialisierung steigt die Abhängigkeit von Lieferanten.

Zentrale und Niederlassung: Die Globalisierung der Märkte führt ebenso zu
einer Dezentralisierung der Unternehmen. Neue Niederlassungen werden gegründet und der Bedarf an standortübergreifenden Integrationen steigt.

Organisatorische Schnittstelle: Durch Arbeitsteilung wird ein Geschäftsprozess
in immer kleinere Teilprozesse zerlegt.
35
Vgl. Bögli (2007, S. 78); Wölfle (2006, S. 7)
36
Heinrich et al. (2004, S. 370)
37
Vgl. Krallmann (2012, S. 107)
38
Vgl. Ruile (2006, S. 135–136)
8

Warenfluss und Informationsfluss: Sowohl Waren- als auch Informationsfluss
werden entlang der Wertschöpfungskette immer weiter aneinander gekoppelt.

Mensch, Aufgabe und Technologie: Die informationstechnische Verarbeitung
ist eine nötige Voraussetzung für die Erfüllung der betrieblichen Aufgaben geworden.
Auf technischer Ebene sollten Schnittstellen auf der Basis von Standards definiert
werden. Die Notwendigkeit von Standards zur Integration zeigt auch eine Analyse
von Schubert. Mittels Mehrfachfallstudie zeigt die Autorin, dass die Praxis zwar eine
Fülle an unterschiedlichen technischen Ansätzen für Integration („Business Collaboration“) bietet. Allerdings liegt auch nach mehr als fünfzig Jahren, in denen EDI in der
Praxis angewendet wird und seit mehr als zwanzig Jahren nach dem Aufkommen
von ERP-Systemen, der Grad der Standardisierung im elektronischen Austausch von
Informationen und Geschäftsdokumenten weit hinter den Erwartungen. „Man könnte
erwarten, dass heute bereits jede Business Software mit einer entsprechenden
Schnittstelle für den Versand von strukturierten Geschäftsdokumenten basierend auf
internationalen Inhalts- und Übertragungsstandards ausgestattet wäre. Die Lösungen
[…] zeigen, dass dem nicht so ist“.39 Die technologischen Fortschritte haben dabei
das Interesse an den Auswirkungen von Technologie auf das Individuum, die Organisation, ihre Prozesse und ganze Industrien noch weiter verstärkt40.
Durch die informationstechnische Verarbeitung ergibt sich eine weitere wichtige
Herausforderung in der betrieblichen Integration, nämlich die Heterogenität von
Informationssystemen41. Heterogenität bezieht sich auf den Grad der Verschiedenheit zwischen Geschäftspartnern42. Die gängige Unternehmenspraxis der letzten
Jahrzehnte begründete es, dass geschäftliche und organisatorische Veränderungen
meist unvollständig und unsystematisch auf der Ebene des Informationssystems
nachvollzogen wurden. Zusammen mit fundamentalen Innovationen haben sich
daraus unterschiedliche, heterogene Applikationslandschaften entwickelt43. Eine
Integration dieser Applikationslandschaften stellt nun das gesamte Unternehmen vor
weitreichende Herausforderungen44. Durch die Ausdehnung über Unternehmens-
39
Schubert (2007, S. 271–272)
40
Vgl. Bjørn-Andersen (2011, S. 3)
41
Vgl. Themistocleous et al. (2002, S. 1088); Schubert (2008)
42
Vgl. Medjahed et al. (2003, S. 62)
43
Vgl. Hafner und Winter (2005, S. 627)
44
Vgl. Schubert (2008)
9
grenzen hinweg, steigt auch die Komplexität noch weiter45, was die Notwendigkeit
nach einer Möglichkeit zur Strukturierung des Integrationsprozesses bedingt.
Informationssysteme sind sozio-technische Systeme, welche nicht nur die technischen Komponenten (Hardware und Software), sondern auch menschliche Komponenten (Nutzer mit unterschiedlichen Motivationen, Qualifikationen und Ansprüchen)
und die organisatorische Umgebung des Systems (im Sinne von Strukturen und
Prozessen) umfassen46. Damit liegen die Herausforderungen in der Integration
keinesfalls nur in der technischen Natur. In Integrationsprojekten wird der Faktor
Mensch in der Literatur teilweise als die größte Herausforderung bezeichnet47. Der
Grund für den Fokus auf die menschliche Komponente liegt ebenso an der Technik,
als dass diese immer leichtgewichtiger und benutzerfreundlicher wird. HTML galt
beispielsweise bis Ende des letzten Jahrhunderts als notwendige, zu erlernende
Sprache im Web, wenn es um die Publikation von Inhalten ging. Mit dem Aufkommen
von HTML Editoren und Content Management Systemen (CMS) änderte sich dies48.
Und Web 2.0 Anwendungen haben gezeigt, wie man ohne Kenntnisse der zugrundeliegenden Sprachsyntax Blogbeiträge veröffentlichen, Wiki-Seiten verfassen oder
sich in sozialen Netzwerken austauschen kann. In Analogie dazu wurden aus der
reinen technischen Kopplung von Daten, umfassende Informationssysteme, in denen
Informationen über Unternehmensgrenzen hinweg fließen und dabei Wissen generiert wird. Der Begriff der Integration meint heute ebenfalls Kollaboration und Nutzerzentriertheit, im Sinne von Web 2.0 – ad-hoc, schnell und unkompliziert. „Doch nicht
nur für die private Nutzung sind Web 2.0 Dienste interessant. Auch für ITVerantwortliche von Unternehmen und die Wirtschaftsinformatik im Allgemeinen kann
die Betrachtung der Systeme und ihrer Charakteristika neue Einsichten zur Unterstützung von Zusammenarbeit und Wissensmanagement in Unternehmen erschließen.“49 Wie bereits erwähnt, wird dieser Einsatz von Konzepten und Technologien
der Web 2.0-Generation im Unternehmenseinsatz unter dem Begriff „Enterprise 2.0“
diskutiert50.
Trotz der Verfügbarkeit von Lösungen (bzw. gerade weil es viele Varianten zur
Lösung gibt), bleibt der Prozess der Integration immer noch eine große Herausforderung für Unternehmen51. Heterogene und komplexe IT-Systeme, organisatorische
45
Vgl. Contreras und Sheremetov (2008, S. 680)
46
Vgl. Orlikowski (1992, S. 398); Picot und Baumann (2009, S. 72); Belfo (2012, S. 311)
47
Vgl. Herzog (2006, S. 33)
48
Gemeint sind HTML Editoren und CMS Systeme, welche nach dem WYSIWYG-Prinzip („what you
see is what you get“) gestaltet wurden.
49
Koch et al. (2007, S. 448)
50
Vgl. McAfee (2006b)
51
Vgl. Perin de Souza und Rabelo (2011, S. 347)
10
Voraussetzungen und viele partizipierende Akteure rufen die Notwendigkeit einer
fundierten methodischen Vorgehensweise von betrieblichen Integrationen hervor52.
Ein Thema, das in der Literatur in diesem Bereich durchgängig als wichtig identifiziert
wird, ist die Bedeutung einer ganzheitlichen, systematischen Sichtweise auf die
Interaktionen zwischen den Akteuren53. Österle und Winter beschreiben diese Situation folgendermaßen:
Egal ob sich das Unternehmen in kleinen, konstanten Schritten verändert, oder radikale
Veränderungen in Geschäftsprozessen und –modellen durchlebt, die Facetten der Veränderung sind vielfältig. Ebenso vielfältig sind die Parameter und Stellschrauben, an denen
ein solcher Veränderungsprozess ansetzen kann. Das wichtigste Kriterium für eine erfolgreiche Veränderung ist jedoch ein methodisches und zugleich ganzheitliches Vorgehen.54
Effizienzverluste entstehen demnach vor allem, wenn dieser Veränderungsprozess
nicht auf der Basis strategisch verankerter Entscheidungen durchgeführt und auf die
Verwendung einer strukturierten Vorgehensweise zur Umsetzung verzichtet wird. Ein
methodisch fundierter, systematischer, holistischer und partizipativer Ansatz zur
Durchführung betrieblicher Integration wird benötigt. Das primäre Ziel dieser Arbeit ist
daher die Konstruktion eines generischen Vorgehensmodells zur Einführung von
betrieblichen Integrationslösungen, das den Anforderungen gängiger Unternehmenspraxis entspricht.
Die globale Zielsetzung dieser Arbeit ist es, aktuelle Möglichkeiten zur
partizipativen Durchführung individueller inner-, über- und zwischenbetrieblicher Integration zu analysieren, diese in einem wissenschaftlich
fundierten Vorgehensmodell zu konsolidieren und dieses Modell bezüglich seiner praktischen Anwendbarkeit in Pilotprojekten zu erproben.
Nachfolgende Forschungsfragen (formuliert als Fragestellungen FS1 bis FS6) zeigen, in welcher Form die bestehenden Möglichkeiten zur Zusammenarbeit analysiert,
systematisiert und zu einem Vorgehensmodell konsolidiert werden, um den Prozess
der betrieblichen Integration methodisch fundiert gestalten zu können.
(FS1) Welche zur Umsetzung betrieblicher Integration anwendbaren Ansätze und
Rahmenwerke können in der wissenschaftlichen Literatur identifiziert werden
und welche Dimensionen und Ebenen sind dabei betroffen?
52
Vgl. Contreras und Sheremetov (2008, S. 680); Eckartz et al. (2009, S. 1599); Thomas et al. (2007,
S. 6); Chan und Swatman (2002, S. 9)
53
Vgl. Power (2005, S. 260)
54
Österle und Winter (2000, S. V)
11
Die Notwendigkeit einer möglichst ganzheitlichen Betrachtung des Themas der
Integration wurde in der Einleitung erläutert. Auf Basis bestehender wissenschaftlicher Literatur wird im ersten Schritt eine wissenschaftlich fundierte Abgrenzung über
das Themengebiet gegeben werden. Dazu ist es zunächst notwendig, den zentralen
Begriff der Integration zu schärfen. Danach werden sowohl praktisch orientierte als
auch theoretisch fundierte Modelle und Rahmenwerke aus wissenschaftlicher Literatur identifiziert und analysiert. Die dadurch ermittelten Ebenen und Dimensionen
stellen den Anwendungskontext für das zu erstellende Vorgehensmodell dar.
(FS2) Wie wird der Bedarf an betrieblicher Integration von österreichischen Unternehmen eingeschätzt?
Die Beantwortung dieser Fragestellung soll Transparenz bezüglich der aktuellen
Situation von Integration in österreichischen Unternehmen schaffen und die Relevanz dieser aufzeigen. Auf der Basis der durch die Beantwortung der Fragestellung 1
gewonnenen Erkenntnisse sowie bestehenden Untersuchungen aus der Literatur
wird ein Instrument zur Beurteilung des Bedarfs an betrieblichen Integrationen entwickelt und zur Anwendung gebracht.
(FS3) Welche Vorgehensmodelle aus facheinschlägiger Literatur können als strukturiertes Vorgehen bei der betrieblichen Integration herangezogen werden?
Nach der Klärung der Grundlagen zur Ermittlung des Forschungskontextes (Beantwortung FS1) werden in diesem Schritt bestehende Vorgehensmodelle für den
gegenständlichen Anwendungskontext identifiziert und analysiert. Zusätzlich sind
Gemeinsamkeiten in der strukturierten Vorgehensweise durch einen Vergleich relevanter Vorgehensmodelle zu ermitteln und daraus die Anforderungen an das zu
entwickelnde Vorgehensmodell abzuleiten.
(FS4) Wie lassen sich in der Praxis bereits erfolgreich durchgeführte Projekte zur
betrieblichen Integration systematisiert erheben, charakterisieren und in den
Kontext dieser Arbeit einordnen?
Ein Instrument zur systematischen Erhebung von in der Wirtschaft bereits erfolgreich
durchgeführten Integrationen wird entwickelt. Dabei werden die Erkenntnisse aus der
Beantwortung der Fragestellung 1 aus der Literatur eingearbeitet. Durch die Anwendung des Instruments werden Praxisbeispiele erfolgreicher betrieblicher Integration
erhoben und einer vergleichenden Analyse unterzogen. Die Praxisbeispiele zeigen
dabei sowohl die methodische Vorgehensweise bei der Umsetzung als auch technische Komponenten, wie die verwendeten Werkzeuge, Standards und Partner der
Integrationsszenarien auf.
12
(FS5) Wie können die Erkenntnisse aus Wissenschaft und Wirtschaft zusammengeführt und zu einem wissenschaftlich fundierten Vorgehensmodell zur Durchführung betrieblicher Integration verschränkt werden?
Die Ergebnisse aus der Bearbeitung der vorangegangenen Fragestellungen bilden
die Grundlage für die Konstruktion des Vorgehensmodells. Neben der wissenschaftlichen Fundierung des Vorgehensmodells (Ergebnis der Fragestellung 1 und 3) werden der konkrete Bedarf der Wirtschaft (Ergebnis der Fragestellung 2) und konkrete
Praxisbeispiele zur Deckung des Bedarfs (Ergebnis der Fragestellung 4) in den Inhalt
einfließen. Dadurch wird die Qualität der Ergebnisse verbessert und es werden die
beiden Zielgruppen - Wirtschaft und Wissenschaft - bestmöglich bedient.
(FS6) Wie kann das Vorgehensmodell auf dessen praktische Anwendbarkeit im
inner-, über- und zwischenbetrieblichen Kontext erprobt werden?
Zur Beantwortung dieser Fragestellung ist es erforderlich, dass das Vorgehensmodell
in der Praxis angewendet wird. Die Evaluation („Proof-Of-Concept“) soll dabei sowohl
die innerbetriebliche bzw. standortübergreifende Integration zeigen, als auch in
einem zwischenbetrieblichen Kontext angewendet werden. Neben der allgemeinen
Vorgehensweise in Integrationsprojekten kann insbesondere der Nutzen von speziellen Methoden zur Partizipation im realen Unternehmenskontext geprüft werden.
Erkenntnisse aus der Anwendung werden nochmals in das Vorgehensmodell rückfließen, sodass nach der Beendigung von Pilotprojekten ein praxiserprobtes Vorgehensmodell vorliegt.
2.2 Thematische Einordnung und Forschungsmethodik
Die vorliegende Arbeit ist der wissenschaftlichen Disziplin der Wirtschaftsinformatik
zuzuordnen. Die Wirtschaftsinformatik beschäftigt sich mit der Entwicklung und dem
Management betrieblicher Informationssysteme als sozio-technische Systeme55. Mit
der zunehmenden Internationalisierung der Wirtschaftsinformatik steht diese Disziplin
der vor allem im anglo-amerikanischen Umfeld vorherrschende Disziplin „Information
Systems Research“ (ISR) gegenüber. Auch wenn die beiden Disziplinen in der Literatur teilweise gleichgesetzt werden56, liegen die Unterschiede vor allem im methodischen Ansatz bzw. in der Betrachtung von Informationssystemen: ISR ist mehr an
den sozialen Aspekten von Informationssystemen interessiert, wohingegen die
55
Vgl. Power (2005, S. 260)
56
Vgl. Zelewski (2007, S. 71)
13
Wirtschaftsinformatik die technische Seite stärker betont57. Obgleich im deutschsprachigen Raum die Gestaltungsorientierung als Forschungsansatz in der Wirtschaftsinformatik dominiert, adressiert sie die gesamte technoökonomische Forschung. Sie
zeichnet sich damit sowohl als verhaltens- wie auch gestaltungsorientierte Disziplin
aus und soll dabei gleichzeitig methodisch fundiert sowie aus Sicht der betrieblichen
Praxis relevant sein58. Ziele der verhaltensorientierten Wirtschaftsinformatik sind die
„Ermittlung und Validierung kausaler, erklärender und/oder vorhersagender Beziehungen zwischen existierenden IS-Phänomenen“59. Damit unterscheidet sie sich
grundlegend von der gestaltungsorientierten Wirtschaftsinformatik, deren Ziele die
„Entwicklung und Evaluation innovativer, nützlicher, übertragbarer Lösungen für
wichtige und relevante IS Gestaltungsprobleme in Wirtschaft und Verwaltung“60 sind.
Gemeinsames Ziel aller Forschungsansätze ist die Verbindung von Stringenz und
Relevanz, also der Forschung anhand theoretischer Strenge („rigor“) und/oder Herstellung des Praxisbezugs der wissenschaftlichen Problemstellung („relevance“)61.
Ob und in welcher Weise wissenschafts-theoretische Stringenz und praktische Relevanz miteinander kombinierbar sind oder im Konflikt stehen, ist Gegenstand eines
andauernden wissenschaftlichen Diskurses („Rigor versus Relevance“ Debatte)62.
Auch Hevner et al. äußern sich in ambiger Weise, indem sie zwar überwiegend den
Eindruck erwecken, dass diese miteinander kombinierbar sind, sich jedoch auch
explizit zu einem Konflikt bekennen63.
Das Forschungsziel der gegenständlichen Arbeit ist die Konstruktion und Evaluation
eines Vorgehensmodells, welches sich sowohl an die Wirtschaft, als auch die Wissenschaft richtet. Damit verfolgt diese Arbeit einen gestaltungsorientierten bzw.
konstruktivistischen Forschungsansatz64. Eine Zielgruppe bilden Forschende, die
im Bereich der betrieblichen Integration von heterogenen Informationssystemen und
damit verwandten Themengebieten tätig sind. Dazu zählen Geschäftsprozesse
ebenso wie Wertschöpfungsnetzwerke und Enterprise 2.0 gestützte Informationssysteme. Die Reflektion des methodischen Vorgehens im Forschungsprozess dient als
Anleitung für Forschende und soll die Stringenz des Ansatzes durch logisches,
nachvollziehbares und verständliches Argumentieren sicherstellen. Wie einleitend
dargelegt ist die wissenschaftliche Problemstellung der Arbeit durch einen hohen
57
Vgl. Stahl (2008, S. 115)
58
Vgl. Winter und Baskerville (2010, S. 257)
59
Winter und Baskerville (2010, S. 257)
60
Winter und Baskerville (2010, S. 257)
61
Vgl. Hevner et al. (2004); Winter und Baskerville (2010, S. 257)
62
Vgl. Mentzer (2008); Vermeulen (2005); Fischer et al. (2010, S. 383–384)
63
Zelewski (2007, S. 76)
64
Österle et al. (2010); Hevner et al. (2004)
14
Praxisbezug gekennzeichnet65. Sie soll einen Beitrag leisten, um die Praxis durch die
Einbringung von Erkenntnissen aus der Praxis zu unterstützen. Sie soll jedoch nicht
durch die Praxis bestimmt werden66. Die Arbeit soll einen Nutzen für Unternehmen
stiften, welche einen konkreten Integrationsbedarf haben und nach einer handhabbaren Lösung für ihr Vorhaben suchen. Die Forschung soll dabei nicht nur auf Großunternehmen abzielen, im speziellen sollen auch KMUs davon angesprochen werden.
Als essentiell in wissenschaftlichen Arbeiten wird die Entwicklung einer geeigneten
Forschungsmethodik erachtet. Die Entscheidung über die Forschungsmethodik
geht der Umsetzung konkreter Forschung voraus und strukturiert dessen Vorgehen67. Nach Österle et al. verläuft dieser idealtypisch in mehreren Iterationen in den
vier Phasen Analyse, Entwurf, Evaluation und Diffusion68:

Analyse: Am Anfang steht die Entwicklung forschungsleitender Fragestellungen. Die Wahl der zum Einsatz zu bringenden Methoden („Methoden-Mix“)
hängt sowohl vom Untersuchungsgegenstand als auch den konkreten Forschungsfragen ab. Forschungsmethodik, Forschungsfragen und MethodenMix sind dabei interdependent zu treffen69. Die Analysephase dient zur Exploration in das Forschungsphänomen. Als typische Forschungsmethoden in dieser Phase werden Umfragen, Fallstudien, Tiefeninterviews mit Experten, oder
die Analyse von Informationssystemen genannt70.

Entwurf: Die im Forschungsprozess zu konstruierenden Artefakte sind anhand anerkannter Methoden transparent herzuleiten. Dafür kommen beispielsweise eine Konstruktion von Demonstratoren und Prototypen, eine Modellierung mit Werkzeugen und die Referenzmodellierung als Methoden in
Frage71.

Evaluation: Die Evaluation ist die „zielbezogene Beurteilung von beliebigen
Objekten zur Ermittlung ihres Wertes auf der Grundlage eines Systems von
Beurteilungskriterien im Feld oder im Labor“72. Zur Evaluation der konstruierten Artefakte können Methoden wie das Laborexperiment, die Pilotierung
(Anwendung eines Prototyps), die Simulation, die Prüfung durch Experten so-
65
Siehe Kapitel 1.
66
Vgl. Roithmayr (2012, S. 151)
67
Vgl. Griese (2005, S. 10)
68
Vgl. Österle et al. (2010, S. 667–668)
69
70
Vgl. Österle et al. (2010, S. 668)
71
72
15
wie das Feldexperiment (Einsatz bei vielen Probanden) zum Einsatz kommen.
Zusätzlich übernehmen die Begutachtungsverfahren für wissenschaftliche
Publikationen („double blind reviews“) einen wichtigen Teil zur Evaluation der
Arbeit73.

Diffusion: Die zielgruppenorientierte Dissemination und Diffusion der Ergebnisse ist von großem Interesse im Forschungsprozess. Dies liegt einerseits an
der Tatsache, dass die Wirtschaftsinformatik einen für die Wirtschaft und Gesellschaft wahrnehmbaren Nutzen stiften soll. Damit wird die Wirtschaft als
Zielgruppe angesprochen. Andererseits wird durch die Publikation in wissenschaftlichen Konferenzen und Journalen der Forderung nach anspruchsvollen
wissenschaftlichen Publikationen nachgegangen74. Es wird die wissenschaftliche Community als Zielgruppe angesprochen und zugleich eine Evaluation
der Artefakte vorgenommen. Instrumente zur Diffusion der Ergebnisse und Erkenntnisse sind daher wissenschaftliche Aufsätze und Konferenzbeiträge,
Praxisaufsätze, Vorträge, Dissertationen, Habilitationsschriften, Lehrbücher,
Vorlesungen, Seminare, Weiterbildung in der Praxis, Anträge auf Fördermittel,
Implementierung in privaten Betrieben und der öffentlichen Verwaltung sowie
Unternehmensgründungen bzw. Spin-offs75.
Die gewählte Forschungsmethodik zur Beantwortung der Fragestellungen (vgl.
Kapitel 2.1) läuft analog zu den von Österle et al. beschriebenen Phasen Analyse,
Entwurf, Evaluation und Diffusion in mehreren Iterationen ab76. Dabei kommen
unterschiedliche Methoden in den Phasen zur Anwendung. Die Analysephase
umfasst eine fundierte Literaturrecherche (siehe Methode in Kapitel 2.2.1), in der
die grundlegenden Begriffe und Konzepte zu identifizieren und zu vergleichen sind.
Mit einer zusätzlichen explorativen Studie (Kapitel 2.2.2) wird die praktische Relevanz des Gesamtkonzepts bestimmt. Für weitere vertiefende Erhebungen sind in der
Analysephase mehrere Praxisbeispiele als Fallstudien (Kapitel 2.2.3) zu erheben
und zu vergleichen.
Die zweite Phase, der Entwurf, umfasst die Modellbildung und Konsolidierung
(siehe Methode in Kapitel 2.2.4). Mithilfe der Erkenntnisse aus der Literaturrecherche, der explorativen Studie und mit Hilfe von Fallstudien kann ein erstes Vorgehensmodell konstruiert werden. Dieses Modell wird in mehreren Iterationen weiter
verfeinert, dh. mit zusätzlicher wissenschaftlicher Literatur und Ergebnissen aus der
Evaluation.
73
74
Vgl. Roithmayr (2012, S. 148)
75
76
16
Die dritte Phase beinhaltet die Evaluation des Vorgehensmodells. Die Überprüfung
der praktischen Anwendbarkeit erfolgt über Pilotierung, dh. es werden Pilotprojekte
durchgeführt (Kapitel 2.2.5). Das Vorgehensmodell soll Integrationsvorhaben für
mehrere Anwendungsszenarien in der Unternehmenspraxis methodisch begleiten.
Ziel ist die Herstellung von produktiven Integrationslösungen für den inner-, über- und
zwischenbetrieblichen Einsatz. Erkenntnisse aus der Anwendung fließen wiederum in
das Vorgehensmodell zurück. Zum Abschluss gibt die Reflexion (Kapitel 2.2.6) eine
Zusammenfassung und kritische Betrachtung der zentralen Ergebnisse sowie einen
Ausblick auf mögliche weitere Arbeiten.
Augenmerk wird auch auf die vierte Phase der Forschungsmethodik, die Diffusion
der Ergebnisse, gelegt. Zum einen müssen für die empirische Erhebung, die Fallstudien und auch für Pilotprojekte zuerst Anwendungspartner aus Wirtschaft und Verwaltung gefunden werden. Zum anderen dienen wissenschaftliche Veröffentlichungen auf Konferenzen und in Journalen neben der Dissemination und Reputation
auch der Evaluation von (Teil-)Ergebnissen. Die Diffusion von Erkenntnissen ist
bereits nach Beendigung der ersten Forschungsmethode zu starten und wird auch
nach Beendigung der Arbeit noch weiter andauern.
Der Erkenntnisgewinn in den einzelnen Phasen des Forschungsprozesses kann als
Reifeprozess beschrieben werden. Ein Reifeprozess, in dem sich das Vertrauen in
das Wissen über das untersuchte Forschungsphänomen im Laufe der Zeit in Form
einer S-förmigen Kurve erhöht77. Abbildung 2 zeigt diesen idealisierten Reifeprozess
und die verwendeten Methoden, um das Wissen im Forschungsphänomen zu festigen.
77
Vgl. Malhotra und Grover (1998, S. 410); Wang et al. (2008, S. 149)
17
Abbildung 2: Die Forschungsmethodik als idealisierte S-förmige Wissenskurve im zeitlichen Verlauf
(Malhotra und Grover78), Zuordnung zu den vier Phasen gestaltungsorientierter Forschung nach
Österle et al.79 und Methoden-Mix der gegenständlichen Arbeit.
In diesem Reifeprozess wird durch das Prinzip der Triangulation ein höheres Maß
an Validität erreicht80. Triangulation ist die „Kombination von Methoden bzw. Methodologien sowie Theorien zur umfassenden Untersuchung eines Phänomens“.81
Wenngleich die Methodentriangulation das prominenteste unter den Triangulationsmodellen darstellt82, werden vier grundlegende Formen der Triangulation unterschieden: Datentriangulation, Forschertriangulation, Theorietriangulation und Methodentriangulation83. Bei der Datentriangulation werden Daten zu einem Phänomen kombiniert, die aus unterschiedlichen Quellen stammen und zu verschiedenen Zeitpunkten,
an unterschiedlichen Orten oder Personen erhoben werden. Die Forschertriangulation setzt verschiedene Beobachter bzw. Interviewer ein, um objektive Einflüsse auf
die Untersuchungsergebnisse zu gewährleisten. Bei der Theorietriangulation werden
Daten zu einem Phänomen unter Einbeziehung verschiedener theoretischer Modelle,
Perspektiven und Hypothesen interpretiert. Zusätzlich unterscheidet man bei der
78
In Anlehnung an Malhotra und Grover (1998, S. 410)
79
80
Vgl. Moran-Ellis et al. (2006, S. 47)
81
Lamnek (2005, S. 736)
82
83
Vgl. Denzin (1970, S. 300ff)
18
Methodentriangulation unter der Kombination von verschiedenen Methoden und der
Einführung von Variationen innerhalb einer Methode84.
In der gegenständlichen Arbeit wird das Prinzip der Triangulation aufgegriffen, indem
Erkenntnisse aus mehreren Quellen zusammengeführt werden. Gerade die Komplexität und Multidimensionalität betrieblicher Integrationen macht eine Triangulation
notwendig. Triangulation findet dabei sowohl innerhalb einer Methode, als auch
zwischen den Methoden Verwendung. Triangulation wird verwendet,

um die erhobenen Daten aus den verschiedenen Methoden zu einem Vorgehensmodell zu konsolidieren (vgl. Kapitel 2.2.4) und

um die Daten innerhalb der Fallstudien zu erheben (vgl. Kapitel 2.2.3).
Im Folgenden wird der Methoden-Mix vorgestellt, welcher sich zur Beantwortung der
einzelnen Fragestellungen ableitet. Die einzelnen Schritte und die gewählten Methoden werden vorgestellt und die erwarteten Ergebnisse dargestellt.
2.2.1 Literaturrecherche
Ziel der Literaturrecherche und -analyse ist die fundierte Erschließung des Forschungskontextes. Am Beginn der Forschungsarbeit steht die Suche nach bestehender wissenschaftlicher Literatur. Die Suche umfasst dabei das Themenfeld der betrieblichen Integration im Allgemeinen sowie Vorgehensmodelle, die für die betriebliche Integration in Frage kommen können. Dadurch werden die Fragestellung 1 (FS1)
und Fragestellung 3 (FS3) beantwortet.
Der Hauptgrund unzureichender Effektivität bestehender Ansätze betrieblicher Integration wird in der mangelnden methodischen Unterstützung bei der Vorgehensweise der Umsetzung vermutet. Um diesen Mangel zu beheben werden allgemeine
Vorgehensmodelle in der Wirtschaftsinformatik untersucht und erste Erkenntnisse für
ein Vorgehensmodell zur Umsetzung betrieblicher Integrationslösungen aus der
vorhandenen Literatur abgeleitet.
Ein weiterer möglicher Mangel bestehender Integrationen ist, dass meist nicht alle
notwendigen organisatorischen und technischen Ebenen in Betracht gezogen werden. Um das Vorgehen bei betrieblichen Integrationen ganzheitlich erfassen zu
können, ist es erforderlich, bestehende Literatur auf Integrationskonzepte hin zu
analysieren und zu systematisieren. Das Ergebnis bilden Konzepte auf unterschiedli-
84
Vgl. Lamnek (2005, S. 159)
19
chen Integrationsebenen mit Beispielen für die Kategorien, um etwaige Abgrenzungsprobleme zu vermeiden.
Durch die Literaturrecherche und -analyse wird eine fundierte Erschließung der
Forschungslücke gewährleistet. Die Literaturanalyse ist der qualitativen Forschungsmethodik zuzuschreiben85. Eine objektive und systematisierte Dokumentation der Ergebnisse gewährleistet die Nachvollziehbarkeit.
2.2.2 Explorative Studie
Ziel dieser Phase ist die Beantwortung der Fragestellung 2 (FS2). Zur Schaffung von
Transparenz bezüglich der aktuellen Situation der betrieblichen Integration in österreichischen Unternehmen wird eine quantitative empirische Erhebung im Zielgebiet
durchgeführt. Basierend auf der Analyse wissenschaftlicher Literatur und einer Recherche relevanter empirischer Studien wird ein Themenkatalog mit Hypothesen
erstellt. Die Bildung von Hypothesen engt zwar die Offenheit der Forschung ein, was
zu Nebeneffekten (wie Selbstbestätigung-, Reaktivitäts- oder Selektionseffekt) führen
kann86, doch begründet sich ein Unterscheidungsgrund zwischen quantitativer und
qualitativer Forschung vor allem in der Bildung von Hypothesen. Hypothesen sind
daher für die Beantwortung dieser Forschungsfrage wichtig.
Da durch die Bearbeitung von FS1 bereits Informationen über den Forschungsgegenstand existieren und aufgrund der Tatsache, dass bereits einige quantitative
Untersuchungen in verwandten Themengebieten bzw. in Teilbereichen des Themengebietes existieren, lassen sich konkrete Hypothesen über den Untersuchungsgegenstand formulieren.
Für eine statistische Auswertung wird ein standardisierter, schriftlicher Fragebogen
zur Bewertung der Hypothesen entwickelt und die Befragung durchgeführt. Die
ausgefüllten Fragebögen werden mittels Korrelationsanalysen, Signifikanztests und
weiteren statistischen Kennzahlen ausgewertet, gegen die Hypothesen getestet und
die Ergebnisse werden diskutiert.
Ein zusätzliches Ziel dieser Untersuchung stellt das Auffinden geeigneter Partnerunternehmen für die weitere Erforschung des Untersuchungsgegenstandes dar. Die
Befragung ist zwar grundsätzlich anonym durchzuführen, soll aber auch die Möglichkeit einer Kontaktaufnahme durch Hinterlassen der Kontaktadresse des ausfüllenden
Unternehmens bieten.
85
Vgl. Lamnek (2005, S. 505–513)
86
Vgl. Gadenne (2001)
20
Die quantitative empirische Erhebung erscheint aus den dargestellten Gründen als
geeignet, um die Forschungsfrage unter Berücksichtigung der Ziele der Untersuchung zu beantworten.
2.2.3 Fallstudien
Ziel dieser Phase ist die Beantwortung der Fragestellung 4 (FS4). Für die Erhebung
von Beispielen aus der Praxis werden Fallstudien durchgeführt.
Fallstudien kommen in der Wirtschaftsinformatik häufig zum Einsatz. Neben Fachund Lehrbüchern zu Fallstudien (wie beispielsweise in „Fallstudien zum Management
von IT-Projekten“ von Riedl und Roithmayr87, „Prozessexzellenz mit Business Software“88 und „Business Collaboration“89 von Wölfle und Schubert, oder „Web 2.0 in
der Unternehmenspraxis“ von Back et al.90) und wissenschaftlichen Veröffentlichungen91 ist die Fallstudie als Forschungsmethode in der Wirtschaftsinformatik anerkannt. Einer Untersuchung von Wilde und Hess92 zufolge finden in der Zeitschrift
„WIRTSCHAFTSINFORMATIK“ Fallstudien mit einer relativen Häufigkeit von 16%
hohen Einsatz93. Damit liegt sie an Platz 2 der Forschungsmethoden der deutschsprachigen Wirtschaftsinformatik hinter den drei Varianten theoretisch-deduktiver
Analysen (formal-, konzeptionell- und argumentativ-deduktive Analyse).
Zweck von Fallstudien ist es ein ganzheitliches und damit realistisches Bild der
sozialen Welt zu zeichnen, indem möglichst alle für das Forschungsphänomen
relevanten Dimensionen in die Analyse einbezogen werden94. Komplexe, schwer
abgrenzbare Phänomene werden dabei in ihrem natürlichen Umfeld untersucht95. So
eignet sich die Fallstudie vor allem zum Verstehen von komplexen Prozessen in
Unternehmen und bietet den Vorteil eine holistische Sichtweise auf die unterschiedlichen Rahmenbedingungen und Wirkungszusammenhänge zu gewinnen96. Yin
87
Vgl. Riedl und Roithmayr (2006)
88
Vgl. Wölfle und Schubert (2006)
89
Vgl. Wölfle und Schubert (2007)
90
Vgl. Back et al. (2009)
91
Vgl. beispielsweise Ash und Burn (2003); Ramdani und Kawalek (2007); Chan und Swatman
(2002); Kim und Pan (2006); Ferneley und Bell (2006); Harland et al. (2007); Smart (2008); Saccani et
al. (2007); Welker et al. (2008); Bengtsson und Agerfalk (2011)
92
Vgl. Wilde und Hess (2007, S. 283)
93
Basis: veröffentlichte Beiträge in der Zeitschrift WIRTSCHAFTSINFORMATIK im betrachteten
Zeitraum Heft 1/1996 bis Heft 6/2006; Analysierte Beiträge: 296.
94
Vgl. Lamnek (2005, S. 299)
95
Vgl. Wilde und Hess (2007, S. 282); McMaster et al. (2007, S. 416–417)
96
Vgl. Gummesson (2000, S. 85–86)
21
unterscheidet zwischen Einzelfallstudien („single-case design“) und MehrfachFallstudien („multiple-case design“)97. Mehrfach-Fallstudien untersuchen das gleiche
Forschungsphänomen in mehreren Ausprägungen und folgen einer einheitlichen
Methodik. Sie gelten deshalb als robuster und lassen vergleichende Analysen zu.
Zusammenfassend nennt Yin drei Kriterien für die Auswahl der richtigen Forschungsmethode im Zusammenhang mit Fallstudien: die Art der Forschungsfrage,
die Kontrolle des Forschers über das untersuchte Objekt und den Fokus auf ein
aktuell auftretendes Phänomen. Fallstudien werden als angemessene Methode
angesehen, wenn es um die Beantwortung von Forschungsfragen des „Wie“ und
„Warum“ geht. Zudem benötigt der Forscher bei der Fallstudienforschung keine
Kontrolle über das untersuchte Objekt und die Fallstudie sollte auf ein aktuelles
Phänomen fokussiert sein98.
Eine Erhebung von unterschiedlichen Integrationslösungen im Rahmen einer durchzuführenden Mehrfach-Fallstudie erscheint eine adäquate Vorgehensweise für die
Beantwortung der Fragestellung 4 (FS4): Die Fallstudien untersuchen ein aktuelles
Phänomen in Unternehmen, worauf der Forscher keinen Einfluss hat. Für die Fallstudien werden Unternehmen vor, während und nach einer betrieblichen Integration
unter Betrachtung technischer, organisatorischer, prozessorientierter und wirtschaftlicher Gesichtspunkte untersucht. Die Erhebung wird nach der Methode „PROMET
BECS“99 durchgeführt und erfolgt mittels mündlichen, qualitativen Interviews und
direkter Beobachtung. Zusätzliche Informationen werden durch Dokumentenanalyse
und -auswertung gewonnen. Die Fallstudien zeigen, wie Unternehmen der Herausforderung unternehmensübergreifender Integration auf unterschiedlichen Ebenen
nachkommen, liefern zusätzlichen Inhalt für die Struktur und Phasen des Vorgehensmodells und beschreiben exemplarisch die bei der Integration verwendeten
Werkzeuge, Standards und Umsetzungspartner. Nach Yin bezeichnet man diesen
Typus als holistische Mehrfach-Fallstudie, da die Unternehmen als Ganzes in der
betrieblichen Integration betrachtet werden und mehrere Fallstudien nach gleicher
Methodik durchgeführt werden sollen100. Durch die Erhebung nach gleicher Methodik
können die Fallstudien anschließend einer vergleichenden Analyse unterzogen
werden.
97
Vgl. Yin (2003, S. 39ff)
98
Vgl. Yin (2003, S. 5)
99
Bei „PROMET Business Engineering Case Studies“ (BECS) handelt es sich um ein theoretisch
fundiertes Vorgehensmodell, das die konsistente Erstellung vergleichbarer Fallstudien über das
einzelne Phänomen und den einzelnen Wissenschaftler hinaus ermöglicht. Herausgegeben wurde
diese Methode vom Institut für Wirtschaftsinformatik der Universität St. Gallen. Vgl. Senger und
Österle (2004)
100
Vgl. Yin (2003, S. 39ff)
22
2.2.4 Modellbildung und Konsolidierung
Ziel dieser Phase ist die Beantwortung der Fragestellung 5 (FS5) durch eine Konsolidierung zu einem wissenschaftlich fundierten Vorgehensmodell. Dies erfordert eine
Zusammenführung der wesentlichen Erkenntnisse aus der empirischen Erhebung,
den Fallstudien und Pilotprojekten aus der Praxis sowie aus wissenschaftlicher
Literatur.
Ausgehend von der Dokumentation der Fallstudien und den Analysen aus der Literatur werden diese nach qualitativer Vorgehensweise (analog zu 2.2.1 Literaturrecherche) klassifiziert und aufgearbeitet, dh. es werden Kategorien zur Einordnung von
Beispielen erstellt. Das Vorgehensmodell muss also durch Einarbeitung und Konsolidierung der gewonnenen Erkenntnisse aus Empirie, Praxis und Wissenschaft verfeinert und in mehreren Schritten überarbeitet werden.
Das Ergebnis dieser Zusammenführung ist ein wissenschaftlich fundiertes, umfassendes Vorgehensmodell zur betrieblichen Integration, welches die Anforderungen
von Konzepten auf unterschiedlichen Ebenen abdeckt. Zusätzlich wird die Anwendbarkeit durch konkrete Praxisbeispiele sichergestellt, welche eine Zuordnung von
Fallstudien zu den behandelten Ebenen der Integration und den zur konkreten Umsetzung von Integrationsvorhaben verwendeten Standards, Werkzeuge und Partner
exemplarisch aufzeigt.
Triangulation bezeichnet die Verwendung mehrerer Quellen oder Methoden zur
Untersuchung eines Forschungsphänomens. Wie bereits in den einzelnen Fallstudien das Prinzip der Triangulation Anwendung erfährt101, soll dies auch im Gesamtprozess der Forschungsarbeit positiv zur wissenschaftlichen Qualität beitragen.
Durch Einbeziehung von Praxis und Wissenschaft mittels mehrerer (sowohl qualitativer als auch quantitativer) Methoden werden die Ergebnisse gegengeprüft und so
das Vertrauen in die wissenschaftlichen Erkenntnisse gestärkt102.
Auf dieser Grundlage ist im nächsten Schritt die praktische Anwendung des Vorgehensmodells zu erproben. Die Erkenntnisse aus der Anwendung werden wiederum in
das Vorgehensmodell einfließen, sodass in mehreren Iterationen ein wissenschaftlich
fundiertes Vorgehensmodell entsteht103.
101
Vgl. Yin (2003, S. 97–101)
102
Vgl. Malhotra und Grover (1998, S. 410)
103
Nach mehrmaliger Konsolidierung mittels Triangulation werden die notwendigen Adaptionen am
Vorgehensmodell abnehmen. Die Inhalte des Vorgehensmodells können als vertrauenswürdig angesehen werden, wenn eine Anwendung keine wesentlichen Änderungen mehr bedingt.
23
2.2.5 Durchführung von Pilotprojekten
Ziel dieser Phase ist die Beantwortung der Fragestellung 6 (FS6). Die Durchführung
von Pilotprojekten in realer Umgebung demonstriert die praktische Anwendbarkeit
des Vorgehensmodells und zeigt mögliche Schwachstellen auf. Durch die Durchführung mehrerer Pilotprojekte können die Erkenntnisse daraus mehrmals in das Vorgehensmodell zurückfließen.
Die Überprüfung der praktischen Anwendbarkeit mittels Pilotprojekten im Feld erscheint daher eine geeignete Methode zur Evaluation des konstruierten Vorgehensmodells.
2.2.6 Reflexion
Eine Reflexion stellt den Abschluss der Arbeit dar. Dies beinhaltet eine Zusammenfassung der zentralen Ergebnisse, eine kritische Betrachtung der erzielten Ergebnisse hinsichtlich der zu Beginn der Arbeit formulierten Erwartungen an ein Vorgehensmodell zur inner-, über- und zwischenbetrieblichen Integration sowie einen Ausblick
auf weitere Arbeiten, die an die Ergebnisse dieser Arbeit anschließen können.
2.3 Zusammenfassung
Im gegenständlichen Kapitel wurde der Handlungsbedarf diskutiert und davon die
forschungsleitenden Fragestellungen abgeleitet. Die Arbeit wurde dem gestaltungsorientierten bzw. konstruktivistischen Forschungsansatz zugeordnet und zur
Lösung der Fragestellungen mit einer geeigneten Forschungsmethodik hinterlegt.
Der weitere Aufbau der Arbeit spiegelt den Weg des Erkenntnisgewinns im Forschungsfeld wider und orientiert sich dabei an der Beantwortung der Fragestellungen. Die nachfolgenden Kapitel beschreiben wesentliche Ergebnisse nach der dargestellten Forschungsmethodik. Abbildung 3 zeigt einen Überblick des Aufbaus und
Ablaufs der Forschungsarbeit mit der Zuordnung der Fragestellungen zu jenem
Kapitel, in der sie behandelt werden.
24
Abbildung 3: Aufbau der Arbeit mit Zuordnung zu den in den Kapiteln zu beantwortenden Forschungsfragen (FS1 bis FS6) und den vier Phasen der Forschungsmethodik (eigene Darstellung)
Kapitel 3 gibt einen Überblick über die Grundlagen des Forschungsthemas. Als
Methode zur Beantwortung der ersten Fragestellung (FS1) kommt die Literaturrecherche zur Anwendung. Das Kapitel enthält neben Definitionen der wichtigsten
Grundbegriffe einen Überblick und Vergleich von Integrationsdimensionen und Integrationsebenen. Zusammen stellt dies den anzuwendenden Bezugsrahmen für den
Forschungs- und Anwendungskontext der gegenständlichen Arbeit dar.
Über eine empirische Erhebung werden in Kapitel 4 erste Antworten von Unternehmen zu Fragen der betrieblichen Integration gegeben und dadurch FS2 beantwortet.
Das Kapitel 5 stützt sich ebenfalls auf vorhandenes Wissen, aufbereitet mittels Literaturrecherche und –analyse. Zunächst werden wichtige Definitionen im Umfeld des
Vorgehensmodells wiedergegeben. Danach werden relevante Modelle beschrieben
und einer vergleichenden Analyse unterzogen, wodurch FS3 beantwortet wird. Da-
25
von werden Anforderungen an das Vorgehensmodell für den gegenständlichen
Anwendungskontext abgeleitet.
Kapitel 6 widmet sich konkreten Integrationslösungen aus der Praxis. Das Kapitel
stellt zum Verständnis der komplexen Zusammenhänge von Integrationslösungen
mehrere Fallstudien vor. Ein Fallstudienvergleich und die Einordnung in den Anwendungskontext beantwortet FS4 und liefert detaillierte Erkenntnisse zur Konzeption
des Vorgehensmodells.
Das konsolidierte Vorgehensmodell, welches die FS5 beantwortet, wird in Kapitel 7
vorgestellt. Das Kapitel enthält eine Beschreibung der einzelnen Phasen, die notwendigen Aktivitäten und Ergebnisse sowie eine Zuordnung von Rollen zu den
Aktivitäten. Wie durch die Pfeile in der Abbildung angedeutet, wird das Vorgehensmodell durch die Verwendung mehrerer Quellen und Methoden konsolidiert. Die
Erkenntnisse aus den Kapitel 3, 4, 5 und 6 tragen ebenso zum Modell bei wie das
nachgelagerte Kapitel 8, sodass in mehreren Iterationen ein konsolidiertes Vorgehensmodell entsteht.
Kapitel 8 beschreibt die wesentlichen Schritte und Ergebnisse aus den Pilotprojekten. Die Evaluation des Vorgehensmodells in den Pilotprojekten zeigt die praktische
Anwendbarkeit und beantwortet damit die FS6. Neben der Vorgehensweise in den
Integrationsprojekten wird ein Fokus auf Ergebnisse aus der praktischen Anwendung
einzelner partizipativer Methoden gelegt.
Den Abschluss bildet die Reflexion der Arbeit in Kapitel 9. Dieses Kapitel beinhaltet
eine Zusammenfassung der zentralen Ergebnisse und die kritische Würdigung. Ein
Ausblick auf mögliche weitere wissenschaftliche Themen, welche an die gegenständliche Arbeit anschließen können, komplettiert die Arbeit.
26
Grundlagen der betrieblichen Integration zur Erschließung des Forschungskontextes
3 Grundlagen der betrieblichen Integration
zur Erschließung des Forschungskontextes
In einem ersten Schritt wird mit dem folgenden Kapitel die Bedeutung der betrieblichen Integration für die Praxis und Wissenschaft erläutert. Ziel des Kapitels ist es
den Forschungs- und Anwendungskontext zu ermitteln. Dabei gilt es der ersten
wissenschaftlichen Fragestellung (FS1) nachzugehen: Welche zur Umsetzung betrieblicher Integration anwendbaren Ansätze und Rahmenwerke können in der wissenschaftlichen Literatur identifiziert werden und welche Dimensionen und Ebenen
sind dabei betroffen?
Abbildung 4 zeigt den Aufbau des Kapitels. Zunächst wird der Begriff der betrieblichen Integration analysiert und abgegrenzt (Kapitel 3.1). Daran anschließend werden
Integrationsdimensionen (Kapitel 3.2) sowie Ansätze und Rahmenwerke zur Integration (Kapitel 3.3) im Detail dargestellt. Durch eine vergleichende Betrachtung der in
diesen Kapiteln ermittelten Integrationsdimensionen und Integrationsebenen wird die
wissenschaftliche Fragestellung beantwortet (Kapitel 3.4). Eine Zusammenfassung
bildet den Abschluss des Kapitels (Kapitel 3.4).
Für die fundierte Erschließung des Forschungskontextes wird bereits vorhandenes
Wissens genutzt. Die genannte Fragestellung wird mittels Literaturrecherche und
27
-analyse beantwortet104. Die durchgeführte Literaturrecherche umfasste die Bestände
der Bibliotheken der JKU Linz und der FH Steyr sowie einschlägige wissenschaftliche
Datenbanken. Herangezogen wurden die Online-Verzeichnisse AIS Electronic Library (AISeL) der Association for Information Systems105, IEEE Xplore Digital Library106 (Institute of Electrical and Electronics Engineers), ACM Digital Library107 der
Association for Computing Machinery, ScienceDirect108, Emerald Insight109 sowie
Google Scholar (scholar.google.at)110. In die Recherche wurde die Suche nach
Literaturhinweisen zur Integration allgemein sowie zu Vorgehensmodellen und Konzepten inner-, über-, und zwischenbetrieblicher Integration einbezogen.
3.1 Begriffsbestimmung und –abgrenzung
In diesem Kapitel wird ein Blick auf die technischen Möglichkeiten zur Integration
geworfen, mit denen sich Wissenschaft und Wirtschaft bereits seit den 1960er Jahren
beschäftigen111. Zunächst ist es sinnvoll, einen Überblick und eine Abgrenzung des
Integrationsbegriffs anhand unterschiedlicher Definitionen vorzunehmen, um diese in
einen sinnvollen Zusammenhang im Kontext dieser Arbeit bringen zu können.
Die Habilitationsschrift von Mertens aus dem Jahr 1966 zur automatisierten zwischenbetrieblichen Kooperation112 wird als „erste Qualifikationsarbeit im Fach Wirtschaftsinformatik“113 gesehen. Dies zeigt, dass das Thema der Integration bzw. die
Frage nach dem optimalen Grad der Integration von Beginn an für die Wirtschaftsinformatik von besonderem Interesse war114. Zu dieser Zeit wurden auch erste Arbeiten zur integrierten Architektur betrieblicher Informationssysteme veröffentlicht115 und
104
Siehe dazu auch Kapitel 2.2.1.
105
URL: http://aisel.aisnet.org [13.10.2012]
106
URL: http://ieeexplore.ieee.org [13.10.2012]
107
URL: http://dl.acm.org [13.10.2012]
108
URL: http://www.sciencedirect.com [13.10.2012]
109
URL: http://www.emeraldinsight.com [13.10.2012]
110
Zur Verwendung von Google Scholar sei angemerkt, dass die Datenbank dieser MetaSuchmaschine nunmehr einen Großteil der wissenschaftlich relevanten Literatur abdeckt. Eine
Untersuchung von Meier und Conkling (2008, S. 196) aus dem Jahr 2008 fand eine Abdeckung von
ca. 90%. Einer weiteren Studie von Chen (2010, S. 221) aus dem Jahr 2010 zufolge, wurden bereits
98% wissenschaftlicher Artikel einer Stichprobe in Google Scholar aufgefunden. Eine Kombination aus
Google Scholar mit den weiteren genannten online Verzeichnissen wird daher als adäquater Umfang
an Quellen für die gegenständliche Literaturrecherche erachtet.
111
Vgl. Grossman (2004, S. 391)
112
Vgl. Mertens (1966)
113
Heinrich (2012, S. 252)
114
Vgl. Lehner et al. (1995, S. 133); Leimstoll und Schubert (2005, S. 985)
115
Vgl. Kumar und van Hillegersberg (2000, S. 23)
28
die Wurzeln des elektronischen Datenaustausches mittels Electronic Data Interchange (EDI) sind ebenfalls in den 1960ern zu finden116. Damals war das primäre Ziel
noch die technische Realisierung von unidirektionalen Schnittstellen, um Daten von
einem Unternehmen zu einem Partnerunternehmen zu senden. Die Komplexität war
bei einer direkten Kopplung von Systemen zur 1:1-Kommunikation überschaubar und
die durch die Integration anfallenden Kosten für die Anpassung der Systeme wurden
durch Einsparungen aus dem Einsatz von E-Business (z.B. durch geringere Prozesskosten, Vermeidung von Medienbrüchen, usw.) gedeckt117. Mit der Zunahme der
Kunden- und Lieferantenbeziehungen stieg aber auch die Komplexität des Datenaustausches und Innovationen, hervorgerufen durch Webtechnologien, lieferten die
technologische Basis für neue Arten, Formen und Möglichkeiten zur Kooperation118.
Das Potenzial von E-Business konnte erst mit der flächendeckenden Verfügbarkeit
von Internettechnologien zur Kommunikation entfaltet werden. Dies ermöglichte eine
Kommunikation auf der Basis von XML119 und später die Integration von Geschäftsprozessen mittels serviceorientierter Architekturen120. Mit der Technologie hat sich
auch der Kommunikations- und Innovationsprozess massiv gewandelt. Anstelle von
unidirektionalen Schnittstellen laufen diese Prozesse nun multidirektional ab. Kunden
und Lieferanten sind aktiv über Generierung und Austausch von Informationen über
eine Vielzahl von Kanälen eingebunden121. Voraussetzung für nachhaltigen wirtschaftlichen Erfolg sind eine Ausrichtung und Integration von Geschäftsprozessen122
und die allgegenwärtige Verfügbarkeit von Informationen123 geworden. In den letzten
Jahren haben daher vor allem effektive und schnell zu etablierende betriebliche
Integrationen auf der Basis von Web 2.0 Technologien („Enterprise 2.0“) stark an
Bedeutung gewonnen124.
Die historische Entwicklung der Integrationstechnologien teilen Schubert und Legner
in drei Phasen ein125. Phase 1 bezeichnen sie als EDI/EDIFACT Integration, danach
folgte die XML-basierte Integration (Phase 2), gefolgt von der serviceorientierten
Integration mittels Web Services (Phase 3). Diese Sicht wird aufgrund der Argumentation in der Arbeit um eine vierte Phase, die „Enterprise 2.0“ basierte Integration,
116
Vgl. Bergeron und Raymond (1992, S. 20); Nurmilaakso (2009)
117
Vgl. Lebender et al. (2003, S. 23)
118
Vgl. Themistocleous und Irani (2003, S. 1973); Legner (2009, S. 2762)
119
120
Vgl. Dorn et al. (2007, S. 1); Yao et al. (2011, S. 299)
121
Vgl. Thackeray und Neiger (2009, S. 171)
122
Vgl. Legner (2009, S. 2762)
123
Vgl. He et al. (2006, S. 1757)
124
Vgl. McAfee (2006b); Rohrbeck et al. (2009, S. 421); Gassmann und Enkel (2006, S. 132)
125
Vgl. Schubert und Legner (2011, S. 252)
29
ergänzt. Phase 4 stellt die notwendigen Technologien für leichtgewichtige, schnell zu
etablierende Integrationen zur Verfügung. Tabelle 1 charakterisiert die vier Entwicklungsphasen der Integrationstechnologien. Beachtlich ist hierbei die Geschwindigkeit,
in derer eine neue Entwicklungsphase eingeläutet wird. Lagen zwischen erster und
zweiter Phase noch mehr als 30 Jahre, so hat sich dies auf 10 Jahre (von Phase 2
auf Phase 3) bzw. 5 Jahre (von Phase 3 auf Phase 4) verkürzt.
Tabelle 1: Entwicklungsphasen von Integrationstechnologien126
Phase /
Merkmal
Zeitspanne
Kommunikationsprotokoll
Datenaustauschformat
Integrationsstil
Architektur
Beispiele für
Standards
Strukturiertheit
der Informationen
Phase 1:
EDI/EDIFACT
Phase 2:
Internet, XML
Phase 3: SOA,
Web Services
Phase 4:
Enterprise 2.0
Start in den
1960ern
Proprietär (X.400,
OFTP, FTAM,…)
Textbasiert
(ASCII, Unicode)
Dokumentenorientiert:
EDIFACT
Nachrichten
(asynchron)
Private VANs
(Value-Added
Netzwerk)
EDIFACT, EDI
Referenz
Framework
strukturiert
Start Mitte der
1990er
Internet (TCP/IP
Protokolle)
XML-basiert
Seit Anfang der
2000er
Internet (TCP/IP
Protokolle)
Web Services,
XML-basiert
Serviceorientiert:
Web Services
(synchron)
Seit Mitte der
2000er
Internet (TCP/IP
Protokolle)
XML-basiert
Serviceorientierte
Architektur (SOA)
Leichtgewichtige
Web Architekturen
HTML, RSS,
ATOM
Nachrichtenorientiert: XML
Nachrichten
(asynchron/
synchron)
Web Architekturen
openTRANS,
RosettaNET,
ebXML
strukturiert
SOAP, WSDL,
REST
strukturiert
Informations- und
wissensorientiert
(asynchron/
synchron)
strukturiert und
schwach strukturiert
Integration meint im Allgemeinen die „Herstellung oder Wiederherstellung eines
Ganzen durch Vereinigen oder Verbinden logisch zusammengehörender Teile (entweder als Vorgang oder als Ergebnis)“127 und hat seit Ende der 1960er Jahren nicht
an Bedeutung verloren. Jedoch hat sich gezeigt, dass es Uneinigkeiten in der konsistenten Verwendung gibt128. So haben sich im Laufe der Zeit, insbesondere durch die
Verfügbarkeit von neuen technologischen Möglichkeiten, aber auch aufgrund des
wissenschaftlichen Fortschritts in der Wirtschaftsinformatik und verwandten Wissenschaftsdisziplinen, unterschiedliche Definitionen gebildet129. Spezifische Sichtweisen
in der Auslegung des Begriffes und der jeweilige Anwendungskontext haben die in
126
In Anlehnung an Schubert und Legner (2011, S. 252)
127
128
Vgl. Herden und Zwanziger (2009, S. 1)
129
Vgl. Heinrich et al. (2004, S. 333)
30
Tabelle 2 im Überblick dargestellten und nachfolgend diskutierten Varianten hervorgebracht.
Tabelle 2: Unterschiedliche Ausprägungen bei der Verwendung des Begriffs „Integration“
Integration
(Dechow
und Mouritsen 2005,
S. 726)
(Leimstoll
und Schubert 2005,
S. 985)
(Seel und
Vanderhaeghen
2005, S.
117)
(Norta et al.
2006, S.
834)
(Bussler
2002, S.
147), auch
in (Nurmilaakso
2009)
(Kim und
Park 2008,
S. 1053)
(Chen et al.
2007, S.
524)
(Hu und
Grefen
2002, S.
559)
(Ritz und
Stender
2003, S.
885)
(Huang und
Chung
2003, S. 15)
Sichtweise
E-BusinessIntegration
Collaborative Business
B2B collaboration
Business-tobusiness
(B2B)
integration
(B2Bi)
Ecollaboration
Supply
chain
collaboration
Business-toBusiness
(B2B)
interaction
Ad hoc
application
integration
Business
integration
solution
extern
Quelle(n)
intern
Begriff
Spezifischer
Anwendungskontext
Sonst. Aspekte / Ebenen
ERP Systeme
Prozess, Organisation, Technologie
E-Business
Geschäftsprozesse, Informationssysteme, Wertschöpfungskette (Kundenseitig)
Zwischenbetriebliche Integration
Geschäftsprozesse, Computergestützter Support
-
B2B Geschäftsprozesse, Werschöpfungskette
„klassische“ EDI
Integration durch
elektr. Dokumentenaustausch
Geschäftsprozesse,
Datenaustausch
Supply Chain
Wertschöpfungspartner (Lieferanten und Kunden)
Supply Chain /
Wertschöpfungsnetzwerk
Zwischen zwei
Geschäftspartnern
Geschäftsprozesse und
-netzwerke („all partners into one
virtual network”)
Technische Aspekte („information, service or goods and
money“)
B2B E-Commerce
Technische Aspekte („data,
enterprise software system,
application”)
Web Services
(B2B, EAI, B2C)
Technische Aspekte (Applikationen, Daten, Prozess), Personen
x
x
x
x
x
x
x
x
x
x
Integration
(Heinrich et
al. 2004, S.
333)
(Quantz und
Wichmann
2003, S. 15)
= Berlecon
E-BusinessIntegration
Business
Collaboration
Business
Networking
BusinessIntegrationTechnologien
(Schubert
2008, S.
825, 2007,
S. 268)
(Alt et al.
2000c, S. 2;
Alt und
Österle
2000)
(Lebender
et al. 2003,
S. 10)
Sichtweise
extern
Quelle(n)
intern
Begriff
x
x
x
x
x
x
x
x
Spezifischer
Anwendungskontext
Sonst. Aspekte / Ebenen
Informationssysteme
Technische und Organisatorische
Integration (Mensch, Aufgabe,
Technik)
Anwendungen, Daten/Informationen, Geschäftsprozesse
E-Business unternehmensintern
(EAI) und zwischen
Unternehmen
(B2B)
Standort-, und
unternehmensübergreifend
Prozesse, Informationstechnologie
Intern und externe
Partner
Geschäftskonzept, Geschäftspartner, Services, Netzwerkfähigkeit
EAI und B2B als
Dimensionen
Informationssysteme, Daten,
Geschäftsprozesse
x
x
31
Wie aus Tabelle 2 ersichtlich ist, kann eine Unterscheidung aufgrund der Sichtweise
auf das bzw. die Unternehmen erfolgen, dh. wo wird integriert130. In der Literatur sind
Definitionen zu finden, welche sich auf die innerbetriebliche Sichtweise beschränken131, auf die über- und zwischenbetriebliche Sicht132, oder beide Sichtweisen
gleichermaßen betrachten133. Dechow und Mouritsen sehen beispielsweise die
Integration im innerbetrieblichen Kontext mit Bezug auf ERP-Systeme. Die Autoren
charakterisieren Integration als einen Prozess mit definierten, sich verändernden
Zielen und technologischen sowie organisatorischen Herausforderungen:
„It is a process through which ERP is associated with (organizational) hope, procedure
(that organize various parties in relation to each other), and technology (that inscribes a
130
131
Vgl. Dechow und Mouritsen (2005, S. 726)
132
Vgl. Leimstoll und Schubert (2005, S. 985); Seel und Vanderhaeghen (2005, S. 117); Norta et al.
(2006, S. 834); Bussler (2002, S. 147); Nurmilaakso (2009); Kim und Park (2008, S. 1053); Chen et al.
(2007, S. 524); Hu und Grefen (2002, S. 559); Ritz und Stender (2003, S. 885); Huang und Chung
(2003, S. 15)
133
Vgl. Heinrich et al. (2004, S. 333); Quantz und Wichmann (2003, S. 15); Schubert (2008, S. 825),
(2007, S. 268); Alt et al. (2000c, S. 2); Alt und Österle (2000); Lebender et al. (2003, S. 10)
32
set of local practices). In this process, integration is more than talk because it has numerous varieties of instantiations and punctuations all demonstrating that ERP has certain
things to offer. Even if never settled, integration is thus performed, but it always remains
open-ended for anyone to debate who wants to and have the arguments to get beyond
going concern”.134
Leimstoll und Schubert weisen darauf hin, dass grundsätzlich zwischen externer und
interner Integration unterschieden wird, fokussieren in den weiteren Ausführungen
dann auf die externe Integration. Die Autoren definieren E-Business-Integration als
„die Verbindung von Geschäftsprozessen und Informationssystemen mit dem Ziel, in
einer verteilten Wertschöpfungskette eine zusammenhängende Leistung (für den
Kunden) zu erzeugen.“135 Quantz und Wichmann knüpfen an diese Definition an und
unterstreichen explizit die inner- bzw. zwischenbetriebliche Sichtweise von Integration:
„E-Business-Integration ist die direkte oder indirekte Verbindung von zwei oder mehr bisher allein stehenden E-Business-Anwendungen oder -Datenbeständen mit dem Ziel, geschäftsbezogene Informationen austauschen und Geschäftsprozesse abbilden zu können.
Diese Integration kann unternehmensintern (Enterprise Application Integration) oder zwischen Unternehmen (Business-to-Business-Integration) erfolgen.“136
Wie auch in obiger Definition ist die unternehmensinterne Sichtweise auf Integrationen in der Literatur unter dem Betriff Enterprise Application Integration (EAI) zu
finden und die zwischenbetriebliche Sicht unter Business-to-business (B2B, bzw.
B-to-B) Integration. Der Begriff EAI wird meist im technischen Sinne verwendet und
bedeutet die „Zusammenführung heterogener Daten, Anwendungen und Prozesse
innerhalb von Unternehmensgrenzen. Sie ermöglicht eine Zusammenarbeit ursprünglich unabhängig voneinander entwickelter und funktionierender Systeme. EAI
umfasst dabei nicht nur das Bereitstellen von Adaptern bzw. Konnektoren zu den
einzelnen Anwendungen, wie beispielsweise zu ERP-Systemen, sondern auch das
regelbasierte Routing (mit Routing wird der Weg von Datenpaketen in Netzwerken
bezeichnet) und die Transformation und Übersetzung der Daten.“137 Im Unterschied
dazu meint eine B2B (bzw. B-to-B) Integration die „Fähigkeit, mit Geschäftspartnern
elektronisch zu kommunizieren“138. Dadurch wird „die Vernetzung über Unternehmensgrenzen hinweg ermöglicht. Viele Konzepte und Technologien der B-to-B
Integration basieren auf EAI-Ansätzen. Sie verfahren nach dem gleichen Prinzip: der
134
Dechow und Mouritsen (2005, S. 726)
135
Leimstoll und Schubert (2005, S. 985)
136
Quantz und Wichmann (2003, S. 15)
137
Lebender et al. (2003, S. 20)
138
Nehring (2003, S. 8)
33
Übertragung von Daten, Anwendungen und Prozessen zwischen verteilten Systemen. EAI-Lösungen lassen sich jedoch nicht bedenkenlos in B-to-BIntegrationslösungen überführen. Hier sind vor allem Sicherheitsaspekte zu berücksichtigen. [...] Des Weiteren besteht bei unternehmensübergreifender Datenübertragung eine größere Notwendigkeit, Standards zu nutzen, um die Kommunikation der
unterschiedlichen Systeme zu vereinfachen.“139 B2B Integrationen stellen demzufolge vor allem in Bezug auf Sicherheit und in der Verwendung von Standards, aber
auch hinsichtlich Verfügbarkeit und Prozesse zusätzliche Anforderungen140:

Sicherheit: Eine einfache Authentifizierung und Autorisierung über Benutzer/Passwort-Kombination ist nicht mehr ausreichend. Vielmehr muss eine
B2B Infrastruktur über Zertifikate, digitale Signaturen und Public-KeyVerschlüsselungsverfahren verfügen.

Verfügbarkeit: Eine B2B Infrastruktur muss grundsätzlich rund um die Uhr im
Einsatz sein. Wartungsmöglichkeiten sollten aufgrund der weltweit verteilten
Anbindung von Kunden und Lieferanten viel seltener sein als bei rein internen
Systemen, beispielsweise aufgrund einer Regelarbeitszeit nur zu gewissen
Zeiten vermehrt Zugriffe aufweisen.

Prozesse: Die Einführung von automatisierten unternehmensübergreifenden
Geschäftsprozessen stellt noch immer eine große Herausforderung für die Beteiligten dar. Vielfach wird daher bei einer B2B Integrationslösung nicht von
globalen Prozessen ausgegangen, sondern von lokalen Prozessen mit punktuellem Informations- und Dokumentenaustausch zwischen den Beteiligten.

Standards: Während man bei EAI mit einer überschaubaren Anzahl von anwendungsspezifischen Formaten arbeitet, gilt es bei zwischenbetrieblichen Integrationslösungen üblicherweise eine Vielzahl unterschiedlicher Systeme anzubinden. Komplexe, hierarchisch aufgebaute Geschäftsdokumente (z.B. auf
XML-Basis) müssen zwischen den Beteiligten ausgetauscht werden. Einfache
satzbasierte und damit schwer anpassbare Transformationsfunktionen sind
damit in der Regel überfordert. Die Notwendigkeit zur Nutzung von Standards
und einer flexibel gestalteten Infrastruktur zur Kommunikation zwischen den
Systemen steigt.
Neben der Sichtweise auf die Integration kann aufgrund des Anwendungskontextes
differenziert werden. Dieser kann auf spezielle Technologien wie Web Services141,
139
140
Vgl. Nehring (2003, S. 8)
141
Vgl. Huang und Chung (2003, S. 15)
34
EDI Integration142 oder ERP Systeme143 fokussiert sein, oder einen generalistischeren Ansatz verfolgen und sich mit Informationssystemen, E-Business oder ECommerce auseinandersetzen. Je nach Kontext werden verschiedene Aspekte der
Integration genannt (Was wird integriert?). Diese umfassen einerseits rein technische Aspekte bei der Integration von Daten, Informationen, Applikationen und/oder
Prozesse. Darüber hinaus werden Peer-to-Peer Ansätze zur Integration144 sowie adhoc Technologien wie Bluetooth145 zum möglichst zeitnahen und direkten Datenaustausch auf technischer Ebene vorgeschlagen. Auch Bussler zielt auf technikzentrierte Integration mittels „klassischem“ EDI ab:
„The goal of business-to-business (B2B) integration is to connect enterprises with their
trading partners electronically through organized business event exchanges containing
business data in order to conduct business between enterprises. Ideally, all business
event interactions take place over networks like the Internet or VANs and do not require
any human intervention.” 146
Viele der Definitionen verstehen unter Integration allerdings nicht nur technische
Gegebenheiten. Huang und Chung führen beispielsweise (trotz ihres Fokus auf
technische Aspekte von Web Services) den Faktor Mensch an:
“A business integration solution is defined as an e-business application that arises from
integrating several enterprise applications, data sources, and collaborators (people) by
using several execution artifacts including process flows, process logic, and connectivity
adapters.”147
Die Einbettung des Menschen in die Organisation wird vor allem bei Definitionen im
weiteren Sinn (wie Informationssysteme, E-Business) als wichtiger Aspekt genannt.
Hierfür kommt der Berücksichtigung von Geschäftsprozessen, wie auch in bereits
erwähnten Definitionen, eine zentrale Rolle zu. Lebender et al. verstehen in diesem
Zusammenhang:
„Die Aufgabe von Business-Integration-Technologien ist es, über verschiedene, heterogene Informationssysteme hinweg, Daten unterschiedlicher Formate automatisiert auszutauschen, so dass keine manuellen Eingriffe nötig sind. Gleichzeitig gilt es auch die Ebene der Geschäftsprozesse zu berücksichtigen, so dass ein optimierter Gesamtworkflow
142
Vgl. Bussler (2002, S. 147); Nurmilaakso (2009)
143
144
Vgl. Kupsch und Werth (2003); Joung und Chuang (2009)
145
Vgl. Ritz und Stender (2003, S. 885)
146
Bussler (2002, S. 147)
147
Huang und Chung (2003, S. 15)
35
entsteht. Ziel ist hierbei die Integration so durchzuführen, dass eine homogene Sicht auf
die verschiedenen Systeme entsteht.“148
Chen et al. merken an, dass Geschäftsprozesse über Unternehmensgrenzen hinweg
gesehen werden müssen und daher die zwischenbetriebliche Kollaboration essentiell
zur Leistung in der Wertschöpfungskette beiträgt. Die Autoren verwenden den Begriff
“Supply Chain Collaboration” als “integrating all partners into one virtual network with
common goals. It is important in achieving competitive advantage”149. Ebenso verstehen Norta et al. unter dem Begriff “B2B Collaboration”: “companies are pursuing
the objective of electronically linking their business processes for improving their
supply chains”150. Dies deckt sich auch mit dem Verständnis von „Business Collaboration“ nach Schubert als „die Unterstützung von standort- bzw. unternehmensübergreifenden Prozessen durch Informationstechnologie“151.
Die Wichtigkeit von Kollaboration bzw. Collaboration (engl.) wird bereits durch die
Verwendung desselben in den zuvor genannten Begriffen „B2B Collaboration“,
„Business Collaboration“ und „Supply Chain Collaboration“ ausgedrückt. In Anlehnung an Welker et al. wird Kollaboration in der gegenständlichen Arbeit als eine
Schlüsselkomponente in der betrieblichen Integration gesehen. Dass sowohl Integration als auch Kollaboration wesentlich zur Leistungssteigerung in Wertschöpfungsnetzwerken beitragen, ist weitgehend anerkannt und empirisch belegt152. Kollaboration meint jenen Prozess, der die Menschen innerhalb und zwischen Unternehmen
verbindet, um „etwas gemeinsam zu entwickeln“153. In diesem Fall ist es „die bewusste und zielgerichtete Organisation einer arbeitsteiligen Wertschöpfung“154. Der Begriff
der Kollaboration sieht meist den Menschen im Mittelpunkt einer Integration. Die
verhaltensorientierten und „weichen“ Faktoren sind daher wichtige Komponenten, die
es in Integrationsvorhaben zu berücksichtigen gilt155.
Auf die Notwendigkeit der Entwicklung zwischenmenschlicher Beziehungen weisen
ebenfalls Alt et al. hin. Sie sehen den Begriff „Business Networking“ als zentrales
Geschäftskonzept für Unternehmen im Internet-Zeitalter, mit Informationstechnik als
Enabler zum Management von Beziehungen zu internen und externen Geschäfts-
148
149
Chen et al. (2007, S. 524)
150
Norta et al. (2006, S. 834)
151
Schubert (2008, S. 825)
152
Vgl. Welker et al. (2008, S. 706)
153
Vgl. Pang und Bunker (2007, S. 6)
154
Wölfle (2007, S. 1)
155
Vgl. Natour et al. (2011, S. 504)
36
partnern156. „Im Mittelpunkt steht die Orientierung am Kundenproblem sowie die
Fähigkeit dafür maßgeschneiderte Problemlösungen zu günstigen Kosten und hoher
Qualität anzubieten. In erster Linie erfordert dies integrierte Leistungen [...] Die
Fähigkeit schnell und effizient Beziehungen zu diesen Geschäftspartnern aufzubauen – die Netzwerkfähigkeit – und der informationsbasierte Mehrwert durch Services
gehören zu den wichtigsten unternehmerischen Zielsetzungen im Zeitalter des Internet.“157 Die von den Autoren geforderte Netzwerkfähigkeit ist eine Form der Kollaboration zwischen Akteuren, bei denen die klassische Linienorganisation einer Netzwerkstruktur weicht. Die Wertschöpfungskette formiert sich zu einem Wertschöpfungsnetzwerk. Dies erfordert eine flexible und durchgängige Struktur, die eine
einfache Kommunikation von heterogenen Plattformen über Unternehmensgrenzen
hinweg ermöglicht, welche sich durch serviceorientierte Architekturen (SOA) realisieren lassen158. Das SOA Konzept soll einer Umfrage von AMR Research zufolge
neben flexibleren und effizienteren Geschäftsprozessen, die Betriebskosten der IT
vermindern, die Sicherheit erhöhen, die Geschwindigkeit bei Softwareupgrades
erhöhen und Technologien „nahtlos“ integrieren lassen159.
Eine Betrachtung des Integrationsbegriffs zeigt die Vielfältigkeit dieser Thematik in
der Wirtschaftsinformatik. Der Mensch, die Organisation, Geschäftsprozesse, Services im Unternehmen und im Wertschöpfungsnetzwerk, all diese unterschiedlichen
Dimensionen, Aspekte und Ebenen der Integration rücken immer deutlicher in den
Vordergrund und werden daher für die gegenständliche Arbeit als wichtig angesehen. Die Basis von technischer Integration bilden Normen, Standards und Formate
für den elektronischen Datenaustausch (insbesondere EDIFACT als branchenunabhängiges, internationales Austauschformat), welche die Voraussetzungen für die
organisatorische Umsetzung schaffen160. Ausgehend von diesen Erkenntnissen gilt
es, für diese Arbeit einen Bezugsrahmen aus Dimensionen und Ebenen der Integration sowie deren Standards zu erarbeiten.
156
Vgl. Alt et al. (2000c, S. 2)
157
Alt und Österle (2000)
158
Vgl. Dorn et al. (2007, S. 1)
159
Vgl. Hill (2006, S. 56)
160
Vgl. Heinrich (1999, S. 70)
37
3.2 Integrationsdimensionen: Technologie, Organisation und
betriebliches Umfeld als Rahmen für eine holistische Betrachtung
Betriebliche Integration tritt in verschiedenen Ausprägungsformen in der Praxis in
Erscheinung. Bereits die Ausführungen zum Integrationsbegriff machten die Notwendigkeit einer Einteilung und klaren Abgrenzung des Themengebietes deutlich. Dieses
Kapitel geht daher der Frage nach, ab wann es sich um eine Integration im Sinne der
gegenständlichen Forschungsarbeit handelt. Beispielsweise stellt eine reine Bestellung über einen online B2B Marktplatz eine sehr lose Geschäftsbeziehung dar, die
keine betriebliche Integration benötigt. Zusätzlich soll die Frage, wann eine Betrachtung als gesamtheitlich bezeichnet werden kann, in diesem Abschnitt beantwortet
werden.
3.2.1 Arten und Formen der Integration
Mit einer betrieblichen Integration gehen neben der Einführung von neuen Technologien auch neue Arbeitsweisen einher. Diese Einführung aus rein technologischer
Sicht zu studieren würde dem Anspruch einer holistischen Betrachtung nicht gerecht
werden und entspricht auch nicht – wie in den einleitenden Kapiteln bereits dargelegt
- dem Sinne der Wirtschaftsinformatik. Obwohl die Wissenschaft auch viel vom
Studium einzelner Dimensionen komplexer Systeme gelernt hat, geht man ebenso
davon aus, dass dies letztlich zu einem unnatürlichen, unvollständigen und unzusammenhängenden Blick auf ein Forschungsphänomen führt161.
Als Bindeglied zwischen Betriebswirtschaftslehre und Informatik lassen sich in der
Wirtschaftsinformatik die organisatorische und technische Sicht identifizieren162.
Diese explizite Trennung zwischen technischer und organisatorischer Sicht findet
sich etwa auch in Capaldo und Rippa’s Methodik zur Bewertung von ERPSystemen163. Banerjee und Kumar betonen ebenfalls die Wichtigkeit von technologischen und organisationalen Faktoren beim webbasierten Austausch von Geschäftsdokumenten164. Die technische Integration kann wiederum innerhalb eines Informationssystems oder zwischen Informationssystemen stattfinden. Und die organisatorische Integration wird des Weiteren gegliedert in die interne, über- und
zwischenbetriebliche Integration (bzw. Kooperation). Von einer zwischenbetrieblichen
Integration wird gesprochen, wenn es sich um die Erstellung einer Marktleistung
161
Vgl. Burton-Jones und Gallivan (2007, S. 658)
162
Vgl. Heinrich et al. (2004, S. 335); Herden et al. (2006, S. 11); Herden und Zwanziger (2009, S. 6)
163
Vgl. Capaldo und Rippa (2008, S. 4)
164
Vgl. Banerjee und Kumar (2002, S. 96)
38
(Produkt, Dienstleistung) handelt. Wenn keine am Markt verwertbaren Leistungen
erstellt werden, sondern beispielsweise die Interessen der Partner gebündelt werden
(z.B. Industrie- und Handelskammer), handelt es sich um eine überbetriebliche
Integration. Sind die Partner rechtlich nicht selbständig, wie zum Beispiel im Falle
eines Konzerns, spricht man von einer innerbetrieblichen Integration165.
In einer Partnerschaft unterscheidet Walters166 zwischen der „Information Rich“, der
„Relational Exchange“ und der „Joint-Learning“ Strategie. Eine „Information Rich“
Strategie fokussiert auf die effektive Aneignung, Verteilung und Verwertung von
relevanten Informationen für die jeweiligen Partner. Die „Relational Exchange“ Strategie hat Erfolg bei längerfristigen Kunden-/Lieferantenbeziehungen, die nicht durch
Marktkräfte und opportunistisches Verhalten determiniert werden. Persönliche Beziehungen und soziale Netzwerke sind hier ausgeprägt und haben einen hohen Stellenwert für die Geschäftsbeziehung. Die „Joint-Learning“ Strategie basiert darauf,
dass der gemeinsame Austausch von Informationen und Know-How neues Wissen
hervorbringt, welches als Kernkompetenz genutzt, zu Wettbewerbsvorteilen für alle
Partner führt.
Eine weitere Sicht auf zwischenbetriebliche Partnerschaften liefern Lambert et al.167.
Den Autoren folgend, kann die Intensität einer Beziehung von einer unverbindlichen
losen Geschäftsbeziehung auf der einen Seite bis Joint Ventures und vertikale Integrationen168 auf der anderen Seite reichen. Zwischen diesen beiden Seiten konnten
die Autoren über Fallstudien drei Typen von Partnerschaften identifizieren. Eine
Partnerschaft ist definiert als “tailored business relationship based on mutual trust,
openness, shared risk and shared rewards that yields a competitive advantage,
resulting in business performance greater than would be achieved by the firms individually”.169 „Bei Partnerschaften vom Typ 1 betrachten sich die beteiligten Unternehmen gegenseitig als Partner und koordinieren gewisse Planungs- und operative
Prozesse. Der zeitliche Horizont ist kurzfristig und meist ist jeweils nur eine Funktion
oder Abteilung innerhalb der jeweiligen Unternehmen beteiligt. Im Fall von Typ 2
dehnt sich der zeitliche Horizont auf eine längere Frist aus, ebenso sind jeweils
mehrere Funktionen oder Abteilungen innerhalb der Unternehmen an der Partner-
165
Vgl. Hagenhoff (2004, S. 9)
166
Vgl. Walters (2008, S. 61–65)
167
Vgl. Lambert et al. (1996, S. 2)
168
Neben der vertikalen Integration, also der Integration zu Kunden und Lieferanten im selben Wettbewerb, werden horizontale Integration (zwischen Wettbewerbern derselben Branche) und diagonale
Integration (zwischen branchenfremden Wettbewerbern) abgegrenzt. Vgl. dazu Heinrich et al. (2004,
S. 335); Schubert und Legner (2011, S. 258). Horizontale, vertikale und diagonale Kooperation wird
fallweise auch als „Kooperationsrichtung“ bezeichnet. Vgl. Hagenhoff (2004, S. 11)
169
Lambert et al. (1996, S. 2)
39
schaft beteiligt. Prozesse werden über Unternehmensgrenzen hinweg integriert. Im
Fall von Typ 3 betrachten die Unternehmen sich gegenseitig als unmittelbare Erweiterung ihrer eigenen Aktivitäten. Die Partnerschaft ist auf Dauer ohne explizites
Enddatum ausgelegt.“170
Da alle drei Typen von Partnerschaften gemeinsame koordinierte Aktivitäten und
Prozesse benötigen, sind diese für die gegenständliche Arbeit von Interesse. Nicht
im Fokus dieser Arbeit sind allerdings lose Geschäftsbeziehungen, die keine betrieblichen Integrationen und Projekte zum Schaffen von Integrationslösungen bedingen.
Aus Sicht der betrieblichen Integration ebenfalls interessant sind Joint Ventures und
vertikale Integrationen, da für diese Arten wiederum integrierte Lösungen zu schaffen
sind. Somit lässt sich festhalten, dass es sich um eine Integration im Sinne der
gegenständlichen Forschungsarbeit handelt, wenn zumindest ein Bekenntnis zu
einer Partnerschaft vorhanden ist und diese eine gewisse, wenn auch kurzfristige,
Kommunikation voraussetzt, was ab Typ 1 gegeben ist.
Aus technischer (bzw. sozio-technischer) Sicht setzt die betriebliche Integration
eine Nutzung von Informationssystemen voraus171. Informationssysteme, die über
Unternehmensgrenzen hinweg eingesetzt werden, werden auch als Interorganisationale Informationssysteme (IOS) bezeichnet172. Nach dem Grad der Integration können nach Premkumar drei IOS-Arten unterschieden werden173: Informationssysteme
zur zwischenbetrieblichen Kommunikation, Koordination und Kooperation. In der
einfachsten Form werden IOS zur elektronischen zwischenbetrieblichen Kommunikation verwendet. Dabei stellt das IOS die Basisinfrastruktur zur elektronischen Übermittlung von Nachrichten bereit. Diese Nachrichten sind meist nicht mit weiteren
betrieblichen Informationssystemen integriert. Diese Form ist beispielsweise bei
anfänglichen EDI-Implementierungen anzutreffen, wenn neue Partner eine EDI
Nachricht zwar annehmen, aber danach nicht mehr automatisiert weiterverarbeiten.
Bei der zweiten Form, der Koordination, sind die internen Informationssysteme
ebenfalls integriert. Damit können Nachrichten von Partnern auch intern automatisiert
weiterverarbeitet werden. Bei einer Kooperation, der dritten Form, Teilen die Partner
zusätzlich gemeinsame Ziele. Kooperationen können auf unterschiedlichen Ebenen
stattfinden und dabei sind mehrere Funktionen oder Abteilungen innerhalb der jeweiligen Unternehmen beteiligt. Den unterschiedlichen Begriffen der Kooperation in der
Literatur ist im Wesentlichen gemein, dass „zwischen den an einer Kooperation
170
Strahringer (2009, S. 98–99)
171
Informationssysteme in der Wirtschaftsinformatik sind per Definition sozio-technische Systeme und
müssen daher aus beiden Sichten betrachtet werden. Vgl. Power (2005, S. 260); Picot und Baumann
(2009, S. 72). Siehe dazu auch Kapitel 2.1.
172
Vgl. Hu et al. (2010, S. 1); Liu et al. (2011, S. 153)
173
Vgl. Premkumar (2000, S. 59)
40
beteiligten Unternehmen eine Zweckbeziehung besteht, mit dem Ziel, betriebliche
Aufgaben über ‚normale‘ Markbeziehungen hinaus zu ergänzen“.174
Ein gemeinsames Bild aus Sicht auf die Organisation und auf das Informationssystem kann gezeichnet werden, wenn Kommunikation, Koordination und Kooperation,
die IOS-Arten nach Premkumar, den Typen einer Partnerschaft von Lambert et al.
gegenüberstellt werden. Strahringer folgert daraus, dass bestimmte technische
Unterstützungsarten verschiedene Anforderungen an die Qualität der zugrunde
liegenden Partnerschaften aus organisatorischer Sicht stellen175 (siehe Abbildung 5).
Abbildung 5: Eignung von IOS-Arten zur Unterstützung von Partnerschaften176
Wie aus der Abbildung ersichtlich, werden bei Partnerschaften vom Typ 1 bereits
Informationssysteme zur Unterstützung der Kommunikation benötigt. Obwohl der
zeitliche Horizont meist kurzfristig ist, werden gewisse Planungs- und operative
Prozesse unterstützt. Da eine Kooperation ein gewisses Maß an Koordination voraussetzt und Koordination in der Regel Kommunikation benötigt, sind auf soziotechnischer Ebene daher Informationssysteme zur Kommunikation ebenso relevant
wie zur Koordination und Kooperation177.
Ein in letzter Zeit häufig in diesem Zusammenhang verwendeter Begriff ist jener der
Kollaboration178. Im Kontext von Blogs und Wikis spricht man mittlerweile fast
selbstverständlich von einer „kollaborativen Wissensgenerierung“. Dabei wird der
Begriff Kollaboration oftmals synonym mit Kooperation verwendet179. Kollaboration ist
allerdings eine erweiterte Form der Kooperation, bei der räumlich verteilte Aufgabenträger, Teilaufgaben am selben Artefakt gemeinsam durchführen180. Die Kooperation
bildet grundsätzlich den strategischen Rahmen für die Zusammenarbeit und ermög-
174
Hagenhoff (2004, S. 9)
175
Vgl. Strahringer (2009, S. 99)
176
In Anlehnung an Strahringer (2009, S. 99)
177
Die drei Arten der Unterstützung durch Techniksysteme decken sich auch mit dem sog. 3K-Modell
(Koordination, Kommunikation, Kooperation) nach Teufel et al. (1995, S. 26f) aus dem Forschungsgebiet des Computer Supported Cooperative Work (CSCW).
178
Siehe dazu auch die Definitionen zum Integrationsbegriff aus Kapitel 3.1
179
Vgl. Schmalz (2007, S. 1)
180
Vgl. Karle und Oberweis (2006, S. 81)
41
licht die Durchführung von kollaborativen Teilaufgaben181. Da die Teilaufgaben bei
der Kollaboration nicht im Vorhinein arbeitsteilig aufgetrennt werden, macht erst die
Verwendung von State-of-the-art Integrationstechnologien das Prinzip der Kollaboration überhaupt möglich182. Dies setzt auch voraus, dass diese Technologien spezielle
Funktionalitäten „zur Sicherstellung eines konsistenten, einheitlichen und weiterverwertbaren Arbeitsergebnisses aufweisen können“183. Neben der Technik zur Erfüllung der Aufgaben ist es vor allem der Mensch, der bei einer Kollaboration im Mittelpunkt steht184, dh. neben einer formalen Ebene (Geschäftsprozess, Arbeitsvorgang)
ist auch immer eine informelle, kulturelle Ebene betroffen185. Aus diesem Grund wird
die Gestaltung von sowohl technisch-strukturellen Elementen (im Sinne von Integration) als auch human-zentrierten Aspekten (im Sinne von Kollaboration) in dieser
Arbeit als essentiell erachtet. Die erfolgreiche Umsetzung von Integrationslösungen
hängt folglich neben einem aufbereiteten technischen IT-Umfeld in Form von Werkzeugen bzw. Technologie („Readiness“), auch von der Offenheit, Innovationsfreudigkeit und der Bereitschaft zum Wandel („Willingness“) ab186.
Wie bereits erwähnt, ist die Frage nach dem optimalen Grad der Integration für die
gegenständliche Arbeit von besonderem Interesse187. Der Zusammenhang zwischen
dem Integrationsgrad und dem Grad der Zusammenarbeit im Sinne von Kollaboration
wird in der Abbildung 6 aufgezeigt. Wie zuvor diskutiert, bildet jede der vier genannten Arten der Zusammenarbeit (Kommunikation, Koordination, Kooperation und
Kollaboration) einen „Baustein“ für die jeweils nachfolgende Art. Wenn man sich auf
dem Kontinuum von der Kommunikation, hin zur Kollaboration bewegt, erhöht sich
auch die Risikobereitschaft für gemeinsame Ziele einzutreten sowie das Engagement
und die Ressourcen, die Teilnehmer in die gemeinsamen Bemühungen investieren
müssen. Jede dieser Art benötigt auch einen höheren Grad an Integration188. Eine
Partnerschaft zum Austausch von EDI Nachrichten, ist ohne eine tiefgreifende Kollaboration möglich, benötigt aber bereits Mittel zur elektronischen Kommunikation. Der
Grad der Integration ist in diesem Beispiel als niedrig anzusehen, wenn Nachrichten
nur extern ausgetauscht und keine weiteren technischen Systeme angebunden
181
Vgl. Rashid et al. (2006, S. 7)
182
Vgl. Schmalz (2007, S. 10)
183
Karle und Oberweis (2006, S. 81)
184
Vgl. Natour et al. (2011, S. 504)
185
Vgl. Eschenbächer (2010, S. 34)
186
Vgl. Ash und Burn (2003); Berthon et al. (2008); Fathian et al. (2008); Tan Ter Chian (2010);
Franken et al. (2009, S. 51); Holtzblatt et al. (2010, S. 4666)
187
Vgl. Lehner et al. (1995, S. 133); Leimstoll und Schubert (2005, S. 985)
188
Vgl. ECOLEAD (2007, S. 9); Eschenbächer (2010, S. 38)
42
werden. Ebenso ist der benötigte und damit optimale Grad der Zusammenarbeit
niedrig.
Abbildung 6: Zusammenhang zwischen Integration und Kollaboration189
Mit der betrieblichen Integration sind in weiterer Folge neben der technischen Gestaltung von strukturellen Elementen, wie dem elektronischen Austausch von Geschäftsdokumenten, auch immer die human-zentrierten Aspekte kommunikativer, koordinativer, kooperativer und kollaborativer Zusammenarbeit gemeint. Das Ziel ist die
Herstellung eines optimalen Grades an Integration zur Zusammenarbeit.
3.2.2 Erklärungsansätze zur betrieblichen Integration: Verbreitung und
Akzeptanz von Technologie
Integration und Kollaboration sind für die Durchführung von inner-, über- und zwischenbetrieblicher Zusammenarbeit notwendig. In diesem Zusammenhang stellt sich
die Frage nach den Motiven und Gründen für das Eingehen von Partnerschaften,
aber auch nach Faktoren für die Akzeptanz von neuen Technologien in Unternehmen.
189
In Anlehnung an ECOLEAD (2007, S. 9); Eschenbächer (2010, S. 38)
43
In der gegenständlichen Arbeit werden Technologien zur Integration von Unternehmen betrachtet, was für ein Unternehmen als Innovation anzusehen ist. Die Frage
nach der Akzeptanz von neuen Technologien in Unternehmen wurde in der Wirtschaftsinformatik vielfach untersucht. Dabei sind Erklärungsansätze und Theorien auf
individueller sowie auf organisationaler Ebene weit verbreitet. Auf individueller Ebene
wird häufig das Technology Acceptance Model (TAM) von Davis190 zur Beantwortung
von Akzeptanzfragen neuer Technologien herangezogen191. Doch erst wenn Technologien im Unternehmen genutzt werden, stellt sich die Frage nach der individuellen
Akzeptanz, weshalb die organisationale Ebene in vielen Fällen der individuellen
Betrachtungsebene vorgelagert ist192. Auch in dieser Forschungsarbeit stellt sich
zunächst die Frage nach Faktoren zur Entscheidung für bzw. gegen eine Integration
auf organisationaler Ebene.
3.2.2.1 Der Partnerschaftsprozess in Lieferketten
Lambert et al. nennen zentrale Elemente, die für den Aufbau von Partnerschaften in
Liefer- und Wertschöpfungsketten wichtig sind193. Die Entscheidung, ob eine Beziehung eingegangen bzw. fortgeführt wird, hängt zunächst von Einflussfaktoren („Drivers“) und Unterstützungsfaktoren („Facilitators“) ab. Einflussfaktoren („Drivers“)
müssen für jeden Kooperationspartner gegeben sein. Es ist zwar unwahrscheinlich,
dass diese für alle Partner dieselben sind, aber es müssen zumindest für jeden
Partner überzeugende Gründe für das Eingehen einer Partnerschaftsbeziehung
existieren. Zum anderen gibt es unterstützende bzw. moderierende Faktoren („Facilitators“). Diese Faktoren sind zwar nicht zwingend notwendig, sie fördern jedoch das
Wachstum von Partnerschaften zusätzlich. Einfluss- und Unterstützungsfaktoren
führen zu einer Entscheidung für bzw. gegen die Partnerschaft. Die Folge einer
Partnerschaft sind gemeinsame Aktivitäten und Prozesse („Components“), welche
diese aufbauen und erhalten. Das Ausmaß, zu welchem die gemeinsam getätigte
Leistung den Erwartungen entspricht, wird als Ergebnis („Outcome“) bezeichnet. Die
Einflussfaktoren setzen gewisse Erwartungen auf diese Ergebnisse. Die Ergebnisse
wiederum wirken über Feedback auf Einflussfaktoren und unterstützende Faktoren
sowie die Aktivitäten. Abbildung 7 zeigt diese Wirkungszusammenhänge.
190
Vgl. Davis (1989)
191
Vgl. Venkatesh (2000, S. 342)
192
193
44
Abbildung 7: Prozess zum Aufbau von Partnerschaften194
3.2.2.2 Transaktionskostentheorie
Ein entscheidender Einflussfaktor für das Eingehen einer Partnerschaft sind die
damit verbundenen Kosten. Was kostet es dem Unternehmen, wenn es einen Geschäftsprozess oder eine Dienstleistung über Partner integriert? Und wie günstig ist
der Fremdbezug dann im Vergleich zur Eigenerstellung? Unternehmen sind vielfach
mit „Make or Buy“ Entscheidungen konfrontiert. Das Ergebnis kann eine Vergrößerung (Insourcing) oder Verkleinerung (Outsourcing) des Unternehmens bedeuten.
Anders formuliert: Eine Organisation ist solange erfolgreich, als seine Aktivitäten
kostengünstiger Inhouse durchgeführt werden können, als durch den Markt. Ist dies
nicht der Fall, werden diese Tätigkeiten ausgelagert. Eine Verlagerung in Richtung
erhöhter Nutzung von Märkten für die eigene Wirtschaftstätigkeit kann durch die
Transaktionskostentheorie erklärt werden.
In einer umfassenden Studie kamen Dibbern et al. zum Ergebnis, dass die Transaktionskostentheorie (Transaction Cost Theory, TCT) die am häufigsten verwendete
Theorie in der Outsourcing Forschung darstellt195. Nach Williamson196, dem Begründer und bekanntesten Vertreter der Theorie, werden „Make or Buy“ Entscheidung
(bzw. vertikale Integrationen) durch die Transaktionskosten bestimmt. Eine Transaktion, die grundlegende Analyseeinheit der Theorie, ist die Übertragung von Verfügungsrechten an Gütern oder Dienstleistungen zwischen zwei Akteuren. Hinter dem
194
195
Vgl. Dibbern et al. (2004)
196
Vgl. Williamson (2007), (2008)
45
Begriff der Transaktionskosten verbergen sich alle Kosten, die bei der Anbahnung
und Abwicklung von Transaktionen entstehen (z.B. Kosten der Partnersuche und
Verhandlung, Kontrollkosten, oder Durchführungs-, Anpassungs- und Beendigungskosten). Es gibt unterschiedliche Ansätze diese Transaktionskosten zu messen. Eine
vollständige Operationalisierung aller Kosten wurde jedoch noch nicht erreicht, ist
aber auch keine Voraussetzung für den transaktionskostentheoretischen Ansatz197.
Die Transaktionskostentheorie liefert daher auch einen Erklärungsansatz für die
Notwendigkeit von betrieblichen Integrationen. Auf der einen Seite erhöht sich der
Druck auf die Unternehmen zur Effizienzsteigerung. Auf der anderen Seite werden
Outsourcing Lösungen immer attraktiver, da sich durch die Verfügbarkeit von neuen
und verbesserten Internettechnologien und deren Anwendungen die Transaktionskosten in vielen Bereichen drastisch reduzieren lassen. Dies ist auch der Grund für
das stetige, die letzten Jahrzehnte andauernde Wachstum in der Beschaffung von
Geschäftsprozessen und Dienstleistungen aus dem Markt198. Im Ergebnis führt dies
zum Outsourcing bzw. Insourcing von ganzen Geschäftsbereichen, Geschäftsprozessen oder einzelnen Aufgaben, die als Teil der Wertschöpfung wiederum in ein
Gesamtsystem integriert werden müssen.
3.2.2.3 „Diffusion of Innovations“ Theorie
Aus wissenschafts-theoretischer Sicht werden Fragen der Verbreitung bzw. Kommerzialisierung einer neuen Technologie auf organisationaler Ebene häufig mit der
„Diffusion of Innovations“ (DoI) Theorie von Rogers199 begegnet. Die immer kürzer
werdenden Produktlebenszyklen unterstreichen die Wichtigkeit dieses Innovationsprozesses zusätzlich. Der Innovationsprozess ist dabei jener Prozess, in dem eine
Innovation im Laufe der Zeit durch verschiedene Kanäle innerhalb eines sozialen
Systems verbreitet wird. Als Innovation versteht Rogers „an idea, practice, or object
that is perceived as new by an individual or other unit of adoption”200. Für die gegenständliche Arbeit ist die Organisation als soziales System relevant, welches
definiert ist als “stable system of individuals who work together to achieve common
goals through a hierarchy of ranks and a division of labor“201. Eine Integration wird
nach der Definition von Rogers als technologische Innovation angesehen, wenn es
einen wahrgenommenen Neuheitswert für die betroffene Organisation hat. Innerhalb
von Organisationen werden Innovationen aufgrund kollektiver oder autoritärer Entscheidungen gefällt. Kollektive Entscheidungen werden durch einen gemeinsamen
197
Vgl. Williamson (2008, S. 32–33)
198
Vgl. Bjørn-Andersen (2011, S. 4); Malone et al. (1987)
199
Vgl. Rogers (1983), (2003)
200
Rogers (2003, S. 12)
201
Rogers (1983, S. 348)
46
Konsens innerhalb der Organisation getroffen. Autoritäre Entscheidungen werden
nur von wenigen Mitgliedern getroffen, die aufgrund ihrer Position im Unternehmen
über Macht, Status oder Kompetenzen verfügen.202
Ob und wie schnell die Innovation von den Mitgliedern angenommen wird, hängt
dabei von verschiedenen Faktoren ab, wobei eine Unterscheidung in „Drivers“ und
„Facilitators“, wie sie Lambert et al. vorschlagen203, nicht getroffen wird.
Der Prozess der Integration von Geschäftsprozessen und Dienstleistungen ist eine
komplexe und vielschichtige Angelegenheit. Speziell bei der Analyse der Verbreitung
komplexer Technologien gibt die DoI Forschung Anlass zur Kritik, da wichtige Facetten außer Acht gelassen werden. Um komplexe IT-Lösungen mit Integration von
Geschäftsprozessen und Leistungen verschiedener Organisationen zu verstehen,
müssen diese als lernintensive Artefakte mit sozialen Beziehungen und Netzwerkstrukturen auf mehreren Ebenen analysiert werden204. Es benötigt daher eine
ganzheitliche Sichtweise und Ausdehnung auf weitere, nicht-technische Gesichtspunkte.
3.2.2.4 „Technology-Organization-Environment“ Framework
Die Einführung von komplexen Technologien muss aus unterschiedlichen Gesichtspunkten betrachtet und analysiert werden205, denn häufig lauern die Barrieren im
Hintergrund dieser Projekte. Die Technologie per se ist nur eine der Gefahren, weshalb ein Integrationsprojekt scheitert. „Viel häufiger allerdings sind die Gründe wohl in
nichttechnischen oder sozialen, also interpersonellen und organisatorischen Problemen zu suchen, etwa im Widerstand der Beteiligten, den erforderlichen Wandel
mitzutragen oder neue Technologien anzuwenden, in einem Mangel an Kommunikation oder in einer fehlenden Vorbildfunktion des Topmanagements. Ferner spielen
auch strategischer Eigennutz und Vorteilssuche der Beteiligten im Prozess des
Wandels und der Einführung neuer Technologien eine nicht unbeachtliche Rolle“206.
Der Frage nach welchen Dimensionen komplexe technologische Innovationen zu
analysieren sind, gehen Tornatzky und Fleischer nach207. In ihrem „Technology –
Organization – Environment“ Framework (TOE Framework) beschreiben sie drei
relevante Dimensionen, die ein Unternehmen dazu veranlassen, eine technologische
202
Vgl. Rogers (1983, S. 347ff)
203
Siehe Kapitel 3.2.2.1; Vgl. Lambert et al. (1996, S. 4)
204
Vgl. Lyytinen und Damsgaard (2001, S. 173)
205
Vgl. Schubert und Legner (2011, S. 252); Shore (2006, S. 102–103)
206
Picot und Baumann (2009, S. 73)
207
Vgl. Tornatzky und Fleischer (1990)
47
Innovation durchzuführen. Gemäß dem Rahmenwerk wird dieser Prozess von dem
technologischen Kontext (Technology), dem organisatorischen Kontext (Organization) und dem betrieblichen Umfeld (Environment) beeinflusst. Der technologische
Kontext umfasst interne und externe Systeme und Technologien, die für das Unternehmen von Bedeutung sind. Der technologische Kontext, Rückgrat der elektronischen Kommunikation208, beinhaltet sowohl Gerätschaften als auch Prozesse. Der
organisatorische Kontext bezieht sich auf die Eigenschaften und Ressourcen des
Unternehmens, einschließlich der Firmengröße, Grad der Zentralisierung und Formalisierung, Managementstrukturen, die Verfügbarkeit von überschüssigen Ressourcen
und die Vernetzung unter den Mitarbeitern. Der Kontext der betrieblichen Rahmenbedingungen meint die Größe und Struktur der Industrie, die Wettbewerbsintensität
sowie das rechtlich-regulative Umfeld. Die drei Kontexte Technologie, Organisation
und betriebliches Umfeld sind sowohl als Einschränkungen, aber auch als Chancen
für technologiegetriebene Innovationen zu verstehen. Die Kontexte beeinflussen
Unternehmen in der Notwendigkeit zur Suche und Einführung einer neuen Technologie.
Das TOE Framework wird in Forschungsarbeiten als Rahmenwerk zur Erklärung von
Innovationen anhand von Modellen mit unterschiedlichen Einflussfaktoren herangezogen. Die Arbeiten umfassen beispielsweise Erklärungsansätze und -modelle für die
Adoption von interorganisationaler Informationssysteme (IOS) in Lieferketten209, in
KMUs210, oder speziell im Einzelhandel211. Es werden auch Einfluss- und Erfolgsfaktoren für die Verwendung von Standards zur Integration allgemein212, zur Integration
auf elektronischen Marktplätzen213 und Technologien wie Web Services214 oder
RFID215 mithilfe des TOE Frameworks eingeordnet und begründet.
Unter den in der Wirtschaftsinformatik weit verbreiteten und anerkannten Theorien
wird der gegenständlichen Arbeit daher das TOE Framework als theoretischer Rahmen zugrunde gelegt. Dabei werden in Anlehnung an die Arbeiten von Strahringer216
208
Vgl. Robertson (2005, S. 380)
209
Vgl. Chong und Ooi (2008); Strahringer (2009)
210
Vgl. Tan Ter Chian (2010); Ramdani und Kawalek (2007); McMaster et al. (2007, S. 415);
Robertson (2005); Tan Ter Chian (2010); Weng und Lin (2011)
211
Vgl. Chen et al. (2005)
212
Vgl. Nurmilaakso (2009)
213
Vgl. Luvsanbyamba und Chung (2009)
214
Vgl. Xu et al. (2005)
215
Vgl. Madlberger (2008)
216
Vgl. Strahringer (2009)
48
sowie Ash und Burn217 die drei Kontexte Technologie, Organisation und betriebliches
Umfeld herangezogen und in weiterer Folge als Integrationsdimensionen bezeichnet.
Das TOE Framework beschäftigt sich mit den Gründen und Voraussetzungen für
Innovationen, beschreibt allerdings nicht das Vorgehen während eines Integrationsprojektes. Es soll allerdings sicherstellen, dass bei der Entwicklung eines Vorgehensmodells zur betrieblichen Integration alle relevanten Dimensionen berücksichtigt
werden. Es hilft vor allem in den ersten Phasen eines Integrationsprojektes, um die
Motive und Beweggründe für die Integration zu erklären. Für das schrittweise Vorgehen in einem Integrationsprojekt wird jedoch zusätzlich ein Vorgehensmodell mit
konkreten Handlungsempfehlungen und Aktivitäten benötigt.
3.2.3 Einflussfaktoren auf die Entscheidung zur Nutzung von Systemen
und Technologien zur betrieblichen Integration
Unternehmen, die erkannt haben, dass eine Partnerschaft entlang der Wertschöpfungskette zu entscheidenden Wettbewerbsvorteilen führen kann, stehen häufig vor
dem Problem, dass andere an Wertschöpfung beteiligte Unternehmen dieselben
Informationssysteme oder Standards einsetzen sollten. Es ist daher wichtig zu verstehen, durch welche Faktoren die Entscheidung zur Nutzung bestimmter Systeme
oder Technologien beeinflusst wird218. Zusätzlich sind neue Systemen und Technologien auch eng verbunden mit grundlegenden Fragen der Gestaltung von organisationaler Strukturen und des Verhaltens von Mitarbeitern in Organisationen. Integrationslösungen beeinflussen in der Regel die organisatorische Umgebung, in der sie
wirken, signifikant219. Eine Betrachtung gängiger, dh. in der Literatur konsistent
identifizierter Einflussfaktoren, ist für diese Arbeit daher sinnvoll.
Einflussfaktoren wirken positiv oder negativ auf den Integrationsbedarf, der in weiterer Folge die Durchführung eines Projektes zur inner-, über- oder zwischenbetrieblichen Integration zur Folge haben kann. Eine wichtige Herausforderung bei Integrationsvorhaben stellt daher die Überwindung von Barrieren gegen diese Einführung
und Nutzung dar. Die Tabelle 3 zeigt einen Überblick über Literatur, die sich mit
Einflussfaktoren auf Nutzung von neuen Systemen und Technologien befasst. Es
wurden drei Meta-Studien, sechs quantitative Erhebungen, eine qualitative Studie
und drei Arbeiten ohne eigene Evaluation untersucht. Trotz teilweise unterschiedlichem Fokus war die untersuchte abhängige Variable bei allen Arbeiten die Adoption
bzw. Nutzung von innovativen Systemen oder Technologien. Dabei ist darauf hinzu217
Vgl. Ash und Burn (2003, S. 385)
218
219
Vgl. Picot und Baumann (2009, S. 72)
49
weisen, dass bei der Diffusion von Technologien häufig eine Anpassungslücke
entsteht: Die Technologie wird in einem Pilotprojekt eingeführt, erreicht jedoch nicht
den Routineeinsatz in größerem Umfang im Unternehmen220.
Tabelle 3: Einflussfaktoren zur Nutzung von neuen Systemen und Technologien
Quelle
Fokus
Methode zur Evaluation
(Strahringer
2009, S. 100)
(Robertson 2005,
S. 380)
Nutzung von Interorganisationssystemen in der Lieferkette
Framework zur Adoption von B2B
E-Commerce (E-Marktplätzen) mit
Fokus auf KMUs
Adoption von Innovationen
Literaturanalyse (Meta-Studie); Findet 19
Faktoren in Literatur
Literaturanalyse (Meta-Studie); Ermittelt
16 Faktoren
(Tornatzky und
Klein 1982)
(Nurmilaakso
2009)
Nutzung („Use“) von E-Business
Rahmenwerke (EDI-/XML-basiert)
(Zhu et al. 2003)
Nutzen („Value“) von E-Business in
der Finanzdienstleistungsbranche;
stärkster Faktor ist die technologische Integration
Einstellung gegenüber und Adoption von SaaS-basierter Anwendungen (Office, CRM, ERP)
(Benlian et al.
2009)
(Chong und Ooi
2008)
(Madlberger
2008)
(Luvsanbyamba
und Chung 2009)
(Ramdani und
Kawalek 2007)
(Chen et al.
2005)
(Tan Ter Chian
2010)
(Xu et al. 2005)
220
Adoption von RosettaNet Standards; Branche: Elektro- und
Elektronikindustrie
Absicht zur Adoption von RFID im
Fast Moving Consumer Goods
(FMCG)-Sektor
Adoption von B2B E-Commerce (EMarktplätze) aus Sicht von Käufer
und Verkäufer
Adoption betrieblicher Informationssysteme in KMUs
Adoption von IOS im Einzelhandel
Adoption technologischer Innovationen in KMUs
Web Services Adoption
Literaturanalyse (Meta-Studie) und
empirische Überprüfung; Finden insgesamt 30 Einflussfaktoren in 75 Artikeln,
davon 3 Faktoren konsistent signifikant
Empirische Erhebung (N=3619) auf
Datenbasis der europäischen E-Business
W@tch; untersucht werden 6 Faktoren,
davon 5 statistisch signifikant
Empirische Erhebung (N=612) in 10
Ländern; untersucht werden 6 Faktoren,
davon 5 statistisch signifikant
Empirische Erhebung (N=374) in
Deutschland; untersucht werden 6
Faktoren, je nach Anwendung 1 bis 4
Faktoren signifikant
Empirische Erhebung (N=109) in Malaysien; 4 Faktoren untersucht, davon 3
signifikant
Empirische Erhebung (N=113) in Österreich und Deutschland; 5 Faktoren
untersucht, 4 statistisch signifikant
Empirische Erhebung (N=62) in Korea, 8
Faktoren untersucht, 3 Faktoren aus
beiden Sichten signifikant
Qualitative Experteninterviews mit 9
KMUs in England
Modell ohne Evaluation
50
Die Auswahl relevanter Faktoren wurde an Strahringer’s Literaturüberblick angelehnt221. Die Literaturanalyse von Robertson222 lieferte weitere wichtige Einflussfaktoren, ohne dass aber eine zusätzliche Meta-Analyse durchgeführt wurde. Die frühe
Literaturstudie von Tornatzky und Klein förderte insgesamt 30 Faktoren zutage. In
der empirischen Evaluation dieser Meta-Studie konnte allerdings nur bei drei technologischen Faktoren ein konsistent signifikanter Zusammenhang nachgewiesen werden223. Neben allgemeinen Untersuchungen zur Nutzung von technologischen Innovationen im Umfeld von E-Business und betrieblicher Integration, haben einige
Autoren spezialisierte Untersuchungen wie beispielsweise zur Adoption von SaaSbasierter Anwendungen224, RFID225, oder E-Marktplätzen226 durchgeführt. Ramdani
und Kawalek227 fokussieren sich auf die Nutzung betrieblicher Informationssysteme
in KMUs und evaluieren als einzige Quelle mittels qualitativer Methodik.
In den folgenden Kapiteln werden die in der Literatur gefundenen Faktoren - eingeordnet in die Integrationsdimensionen Technologie, Organisation und Umfeld - besprochen. Die Arbeiten mussten eine theoretische Fundierung aufweisen und es
wurden nur Faktoren berücksichtigt, denen in empirischen Evaluationen statistische
Zusammenhänge mit der Adoption von innovativen Systemen oder Technologien
nachgewiesen werden konnte. Demzufolge wurden die drei Modelle ohne Evaluation228 für die Identifizierung von gängigen Einflussfaktoren nicht herangezogen und
Faktoren aus der qualitativen Erhebung wurden nur dann aufgenommen, wenn
diesen in zumindest einer quantitativen Evaluation bereits ein signifikanter Zusammenhang nachgewiesen wurde.
3.2.3.1 Technologische Einflussfaktoren
Die Tabelle 4 zeigt Einflussfaktoren, die der Integrationsdimension Technologie
zuzuordnen sind, im Überblick. Den ersten drei Faktoren, die in Roger’s DoI Theorie
ihren Ursprung haben229, konnte in diversen Studien ein konsistenter Zusammenhang belegt werden. Ausschlaggebend für die Verbreitung sind die technische Kompatibilität, der relative Vorteil und die Komplexität der Technologie in seiner Nut-
221
222
223
Vgl. Tornatzky und Klein (1982)
224
Vgl. Benlian et al. (2009, S. 414)
225
226
Vgl. Luvsanbyamba und Chung (2009); Robertson (2005, S. 380)
227
Vgl. Ramdani und Kawalek (2007, S. 415)
228
Vgl. Chen et al. (2005); Tan Ter Chian (2010); Xu et al. (2005)
229
Siehe Kapitel 3.2.2.3
51
zung230. Zusätzlich stellten sich die Verfügbarkeit von Systemen und Technologien,
der Kosten/Nutzen Aspekt der Investition sowie die Applikationsspezifität als
relevante technologische Einflussfaktoren heraus.
Tabelle 4: Einflussfaktoren der Integrationsdimension „Technologie“
Faktor
Quelle(n)
Komplexität
(Tornatzky und Klein 1982; Strahringer 2009; Robertson 2005;
Chong und Ooi 2008; Ramdani und Kawalek 2007)
(Tornatzky und Klein 1982; Strahringer 2009; Robertson 2005;
Zhu et al. 2003; Nurmilaakso 2009; Ramdani und Kawalek
2007)
(Tornatzky und Klein 1982; Strahringer 2009; Madlberger 2008;
Ramdani und Kawalek 2007)
(Robertson 2005; Luvsanbyamba und Chung 2009)
(Robertson 2005; Madlberger 2008)
(Robertson 2005; Benlian et al. 2009)
Kompatibilität
Relativer Vorteil
Verfügbarkeit
Kosten/Nutzen
Applikationsspezifität
Der Komplexitätsgrad ist einer der wichtigsten Einflussfaktoren für oder gegen die
Nutzung von innovativen Systemen und Technologien. Einfach anzuwendende
Technologien werden in der Regel eher genutzt, als hoch komplexe Systeme. Die
Frage wann eine Innovation als komplex wahrgenommen wird, lässt sich schwer
messen. Wie auch viele andere Faktoren, lässt sich daher die Komplexität nicht
exakt definieren231. Rogers definiert Komplexität als „the degree to which an innovation is perceived as difficult to understand and use”232. Die subjektive Wahrnehmung
einzelner Personen ist für die Einschätzung der Komplexität einer Technologie wichtig. Speziell geschulte, technikaffine Mitarbeiter können daher negative Auswirkungen, die die Komplexität auf den Erfolg eines Projekts haben kann, reduzieren oder
sogar eliminieren233.
Die technische Kompatibilität ist definiert als „the degree to which an innovation is
perceived as being consistent with the existing values, past experiences, and needs
of potential adopters”234. Ein Zusammenhang zwischen der technischen Kompatibilität und dem Projekterfolg konnte bereits in klassischen EDI Implementierungen
empirisch nachgewiesen werden235.
230
Vgl. Tornatzky und Klein (1982, S. 28); Crum et al. (1996, S. 48); Cooper und Zmud (1990)
231
Vgl. Tornatzky und Klein (1982, S. 40)
232
Rogers (2003, S. 16)
233
234
Rogers (2003, S. 15)
235
52
Der relative Vorteil ist „the degree to which an innovation is perceived as better than
the idea it supersedes”236. Auch diese Definition bietet großen Interpretationsspielraum. Es besteht die Möglichkeit einer Auffassung und Messung dieses Faktors an
der Wirtschaftlichkeit, an technischen Vorteilen, an Prozessverbesserungen, oder
einer Kombination dieser Charakteristika. Tornatzky und Klein bezeichnen diesen
Faktor wörtlich als Mülleimer, der jene Charakteristika enthält, die keinem anderen
Faktor sinnvoll zugeordnet werden können237. Aufgrund der häufigen Verwendung
und nachgewiesener positiver Korrelation in der wissenschaftlichen Literatur sollte
dieser Faktor jedoch berücksichtigt werden.
Unter der Verfügbarkeit versteht man einerseits die Unterbrechungsfreiheit bei der
Nutzung238 einer Technologie. Anderseits sollten Technologien auch qualitativ hochwertig und möglichst flächendeckend verfügbar sein, um die Nutzung voranzutreiben239. Ein fortgeschrittener Reifegrad einer Technologie verringert zudem die Risiken, die mit einer experimentellen Technologie verbunden sind.
Eine Kosten/Nutzen Analyse wird üblicherweise für jede größere Investition durchgeführt. Die Überlegungen aus den Investitionskosten heraus stellen somit auch
einen nicht unbeachtlichen Faktor für eine Innovationsdiffusion dar240. Wie durch die
Transaktionskostentheorie erklärt, kann das Ergebnis der Wirtschaftlichkeitsbetrachtung eine Vergrößerung (Insourcing) oder Verkleinerung (Outsourcing) des Unternehmens zur Folge haben241.
Als weiterer Faktor wird der Applikationsspezifität in einigen Studien eine negative
Korrelation mit der Adoption von Technologien nachgewiesen. Dieser Faktor wird
ebenfalls in der Transaktionskostentheorie begründet und ist gerade für Outsourcing
Lösungen (wie beispielsweise SaaS) relevant. Hoch spezifische Applikationen, die
spezifische Geschäftsprozesse und -daten sowie speziell geschultes Personal benötigen, erfordern komplexe Überwachungs-, Anreiz- und Koordinierungsmechanismen,
die effizienter unternehmensintern als über Outsourcing durchgeführt werden können242.
236
Rogers (2003, S. 15)
237
Vgl. Tornatzky und Klein (1982, S. 34)
238
239
Vgl. Luvsanbyamba und Chung (2009, S. 488)
240
241
Siehe Kapitel 3.2.2.2
242
Vgl. Benlian et al. (2009, S. 416); Robertson (2005, S. 380)
53
3.2.3.2 Organisatorische Einflussfaktoren
Die Einflussfaktoren der Dimension Organisation wurden in innerbetriebliche und
über- bzw. zwischenbetriebliche Faktoren unterteilt. Unter den inner-organisationalen
Faktoren (siehe Tabelle 5) werden all diejenigen Einflussfaktoren gefasst, die die
Bereitschaft der Organisation hinsichtlich der System- und Technologienutzung
charakterisieren. Dazu zählen die Unternehmensgröße und die Ressourcen- bzw.
Kapazitätsverfügbarkeit. Des Weiteren ist die Einstellung gegenüber Innovationen
relevant, um ein positives Innovationsklima zu schaffen. Dies drückt sich in den
Faktoren strategischer Wert des Technologieeinsatzes, technologische Expertise, Top Management Unterstützung und Technologievertrauen aus243.
Tabelle 5: Einflussfaktoren der Integrationsdimension „Organisation“ (innerbetriebliche Faktoren)
Faktor
Quelle(n)
Unternehmensgröße
(Strahringer 2009; Robertson 2005; Nurmilaakso 2009;
Ramdani und Kawalek 2007; Zhu et al. 2003)
(Strahringer 2009; Robertson 2005; Luvsanbyamba und Chung
2009; Ramdani und Kawalek 2007; Zhu et al. 2003)
(Strahringer 2009)
Ressourcenverfügbarkeit
Strategischer Wert des Technologieeinsatzes
(Technologische) Expertise
Top Management Unterstützung
Technologievertrauen, Einstellung
gegenüber Technologie
(Strahringer 2009; Luvsanbyamba und Chung 2009; Ramdani
und Kawalek 2007)
(Strahringer 2009; Benlian et al. 2009, 2009)
Die Unternehmensgröße wird in Studien als Kontrollvariable herangezogen, oder es
wird explizit ein Fokus auf das KMU-Segment oder Großunternehmen gelegt. Die
Unternehmensgröße kann an der Anzahl der Mitarbeiter oder dem Umsatz, aber
auch anhand der geographischen Ausdehnung eines Unternehmens (z.B. Anzahl der
Niederlassungen und Zweigstellen in unterschiedlichen Ländern) gemessen werden.
Ein statistischer Zusammenhang zwischen Technologie-Nutzung und Unternehmensgröße konnte nicht immer bestätigt werden244. Dies liegt einerseits daran, dass
kleinere Unternehmen häufig Charakteristika aufweisen, die eine Nutzung von neuen
Systemen und Technologien hemmen können (z.B. Mangel an erforderlichen Ressourcen, aber auch die Unternehmerpersönlichkeit oder die Unternehmenskultur)245.
243
244
Vgl. Benlian et al. (2009, S. 414); Patterson et al. (2003, S. 99); Robertson (2005, S. 380)
245
Vgl. Madlberger (2008, S. 858); Weber (2009, S. 84)
54
Andererseits wurde großen Unternehmen eine strukturelle Trägheit nachgewiesen,
welche eine Diffusion von Innovationen verlangsamt246.
Wie bereits die technische Verfügbarkeit als Faktor besprochen wurde, ist dies auch
aus organisatorischer Sicht notwendig. Die Ressourcenverfügbarkeit reicht dabei
nicht immer aus, neue Systeme und Technologien benötigen oft zusätzliche Ressourcen. In diesen Fällen ist ein Ressourcen- bzw. Kapazitätsüberschuss nötig, um
die Innovation voranzutreiben. Zhu et al. sehen die Ressourcenverfügbarkeit primär
unter finanziellen Gesichtspunkten (dh. Investitionen in Hardware, Software, Integration und Schulungen) und stellen einen positiven statistischen Zusammenhang
zwischen vorhandenem IT-Budget und E-Business Aktivitäten fest247. Zudem ist aus
organisatorischer Sicht die Verfügbarkeit von Personalkapazitäten nötig. Speziell
KMUs wird oft ein Mangel an finanziellen, personellen, kapazitativen oder technischen Ressourcen nachgewiesen248.
Unter den Faktoren zu bereits bestehenden Einstellungen gegenüber der Nutzung
von neuen Systemen und Technologien (strategischer Wert des Technologieeinsatzes, technologische Expertise, Top Management Unterstützung und Technologievertrauen) ist vor allem die Top Management Unterstützung hervorzuheben.
Die Unterstützung des Top Management ist entscheidend für die Umsetzung von
neuen Ideen und Technologien in Organisationen, da diese bedeutende Auswirkungen auf die Geschäftstätigkeit, auch über die Unternehmensgrenzen hinaus, haben
kann249. Die Bereitschaft des Managements zur Unterstützung sollte ebenfalls durch
entsprechende Expertise, Technologievertrauen und eine strategische Verankerung
begleitet werden250.
Neben den innerbetrieblichen Faktoren wirken auch über- und zwischenbetriebliche
Einflussfaktoren auf die Nutzung von neuen Systemen und Technologien. Relevant
sind zunächst die Faktoren auf bilateraler Ebene, das Vertrauen in die Partnerschaft, die Abhängigkeit vom Partner, die Macht des Partners sowie die Verbindlichkeit der Partnerschaft. Wünscht oder schlägt ein Partner die Nutzung eines
bestimmten Systems oder einer Technologie vor, so haben Charakteristika aus
dieser bilateralen Partnerschaft einen starken Einfluss auf die Entscheidung bezüglich der Innovation251. Steht nicht nur ein spezifischer Partner, sondern ein Netzwerk
246
Vgl. Zhu et al. (2003, S. 9)
247
Vgl. Zhu et al. (2003, S. 8)
248
249
250
251
55
von aktuellen und potentiellen Partnern zur kollaborativen Nutzung eines Systems
oder einer Technologie im Zentrum der Betrachtung, reicht die bilaterale Perspektive
allein nicht aus. Ferner gilt es auf der netzwerkbasierten Ebene die Faktoren Netzwerk-Externalitäten, Soziale Verankerung/Einfluss und Netzwerk-Governance
zu beachten252. Tabelle 6 zeigt alle über- und zwischenbetrieblichen Einflussfaktoren
im Überblick.
Tabelle 6: Einflussfaktoren der Integrationsdimension „Organisation“ (über- und zwischenbetriebliche
Faktoren)
Faktor
Quelle(n)
Vertrauen in Partnerschaft
(Strahringer 2009; Robertson 2005; Chong und Ooi 2008;
Luvsanbyamba und Chung 2009)
(Strahringer 2009; Robertson 2005; Chong und Ooi 2008)
(Strahringer 2009; Robertson 2005)
(Strahringer 2009)
(Strahringer 2009)
(Strahringer 2009; Benlian et al. 2009, 2009)
(Strahringer 2009)
Macht des Partners
Abhängigkeit vom Partner
Verbindlichkeit der Partnerschaft
Netzwerk-Externalitäten
Soziale Verankerung/Einfluss
Netzwerk-Governance
Als wichtigster Faktor in über- und zwischenbetrieblichen Partnerschaften ist Vertrauen zu nennen. Robertson sieht das Vertrauen in die Partnerschaft als inhärenter
Faktor über alle anderen Faktoren253. Ohne Vertrauen wäre es beispielsweise sehr
schwierig ein IOS zu implementieren oder E-Marktplätze zu nutzen254. Unternehmen,
die einander vertrauen, sind eher bereit, in diese Systeme zu investieren, um Informationen zu teilen und Wissen zu generieren255. Darüber hinaus kann opportunistisches Verhalten durch Vertrauen eingedämmt werden256. Ein Mangel an Vertrauen
gilt daher als das größte Hindernis einer erweiterten Kollaboration in Wertschöpfungsketten257.
Die drei Faktoren Macht, Abhängigkeit und Verbindlichkeit stehen in einer wechselseitigen Beziehung. Der Einfluss auf die Partnerschaft durch Machtausübung
kann positiv oder negativ auf die Nutzung einer Technologie wirken258. Ein Unternehmen hat eine schlechtere Machtposition, wenn die Verkäufe von ihren Kunden
oder Lieferanten abhängig und diese schwer auszutauschen sind, weil es beispiels-
252
253
254
255
Vgl. Cheng et al. (2008, S. 292)
256
257
Vgl. Ueltschy et al. (2007, S. 15); Panayides und Venus Lun (2009, S. 42)
258
56
weise keinen Ersatz gibt oder es die Verbindlichkeit der Beziehung unterbindet.
Unternehmen mit entsprechender Machtposition sind in der Lage, diese Position
entweder zur Überzeugungsarbeit zu nutzen oder Zwang über ihre Partner auszuüben und auf diese Weise die Nutzung eines bestimmten Systems oder einer Technologie voranzutreiben259.
Wenige Arbeiten befassen sich mit Einflussfaktoren auf netzwerkbasierter Ebene.
Strahringer nennt als wichtigstes Merkmal das Vorhandensein von NetzwerkExternalitäten. Netzwerk-Externalitäten führen dazu, dass der wahrgenommene
Vorteil der Nutzung einer Technologie mit der Zahl der Nutzer steigt. In den Anfangsphasen, bevor ein Netzwerk eine interessante Größe für die Nutzer erreicht hat, kann
der Faktor negativ wirken, danach wird üblicherweise ein positiver Einfluss auf die
Nutzung unterstellt260. Dieser Faktor spielt bei den meisten Enterprise 2.0 Anwendungen (z.B. Projekt-Wikis oder soziale Netzwerke) eine wichtige Rolle, da ihre
Vorteile erst mit steigender Nutzeranzahl zunehmen. Die Literatur spricht von der
kritischen Masse an Nutzern, die für einen sinnvollen Einsatz erreicht werden
muss261.
Ebenso wie bei der bilateralen Betrachtung sind auch auf Netzwerk-Ebene „weiche“
Faktoren mit zu berücksichtigen: So können Vertrauen, Verbindlichkeit, Abhängigkeit
und Zufriedenheit in Bezug auf das Netzwerk unter dem Faktor sozialer Verankerung und Einfluss, oder auch allgemein der Dichte des Netzwerks, zusammengefasst werden262.
Das Vorhandensein und Durchsetzungsvermögen einer Netzwerk-Governance
kann als Gegenstück zu Macht auf bilateraler Ebene gesehen werden. Alternativ
kann auch vom Vorhandensein einer zentralen Instanz mit Durchsetzungsvermögen,
im Sinne von Überzeugungsarbeit oder Zwang, gesprochen werden263.
3.2.3.3 Einflussfaktoren aus dem betrieblichen Umfeld
Ergänzende Einflussfaktoren ergeben sich aus dem betrieblichen Umfeld. Diese
ergeben sich aus der Wettbewerbsintensität, dem Grad der Unsicherheit und dem
generellen Marktumfang der betrachteten Branche. Das Vorhandensein von externen Ressourcen und der regulative Rahmen sind weitere wichtige Faktoren in
dieser Integrationsdimension (siehe Tabelle 7).
259
Vgl. Chong und Ooi (2008, S. 535)
260
261
Vgl. Rogers (2003, S. 343–364); Chui et al. (2009); Dufft und Tietz (2007, S. 18)
262
263
57
Tabelle 7: Einflussfaktoren der Integrationsdimension „Betriebliches Umfeld (Rahmenbedingungen)“
Faktor
Quelle(n)
Wettbewerbsintensität
(Strahringer 2009; Benlian et al. 2009)
(Robertson 2005; Ramdani und Kawalek 2007)
(Robertson 2005; Ramdani und Kawalek 2007)
(Zhu et al. 2003)
Unsicherheit
Branche
Externe Ressourcen
Regulativer Rahmen
Der Druck von Wettbewerbern hat einen positiven Effekt auf die TechnologieNutzung264, da die Wettbewerbsintensität insbesondere das Streben nach Effizienzsteigerung sowie nach Differenzierung und Kundenbindung verstärkt265. In
Märkten mit hoher Wettbewerbsintensität kann eine geringe Veränderung ein Ungleichgewicht verursachen, zu dessen Ausgleich alle Unternehmen der Branche
benötigt werden, bevor Marktanteile und die Branche wieder ins Gleichgewicht
kommen266. Auch wenn die Wettbewerbsintensität die Nutzung von neuen Technologien vorantreibt, so sind es oft die internen, organisatorischen Faktoren, die den
Ausschlag für technologische Innovationen geben267.
Der Faktor Unsicherheit erzeugt ein Streben nach Flexibilität durch Systemnutzung268. Begründet wird Unsicherheit in der Transaktionskostentheorie, wo dem
Faktor hemmende Auswirkungen auf den Grad des Outsourcings nachgewiesen
wurden. Eine höher wahrgenommene Unsicherheit führt zu weniger Outsourcing.
Unsicherheit kann als eine Kombination aus geschäftsbezogener und technologiegetriebener Unsicherheit verstanden werden. Die geschäftsbezogene Unsicherheit
bezieht sich auf das Ausmaß, in dem sich unternehmensspezifische Aspekte in einer
Partnerschaft potenziell verändern können. Die technologiegetriebene Unsicherheit
erfasst jenes Ausmaß, in dem sich erforderliche technische Funktionen oder Schnittstellen im Laufe der Zeit verändern können269.
Die Branche, in dem das Unternehmen tätig ist, hat nicht selten positiven Einfluss
auf eine Technologie-Nutzung. Oft gibt die Branche eine Norm oder einen Industriestandard vor, nach dem eine betriebliche Integration ablaufen muss270.
264
Vgl. Nurmilaakso (2009, S. 10)
265
Vgl. Strahringer (2009, S. 99–100)
266
267
Vgl. Zhu et al. (2003, S. 9)
268
Vgl. Strahringer (2009, S. 99–100)
269
Vgl. Benlian et al. (2009, S. 416)
270
58
Als Pendant zur Verfügbarkeit von internen Ressourcen gilt es das Vorhandensein
von externen Ressourcen zu erwägen. Schnell verändernde Rahmenbedingungen
und die Unterstützung von neuen Technologien durch die Industrie lassen Firmen auf
externe Ressourcen (z.B. Outsourcing des technischen Supports) zurückgreifen271.
Auch regulative Rahmenbedingungen (z.B. Gesetze, Unterstützung) können die
Nutzung von Technologien entscheidend beeinflussen. Eine elektronische Rechnungslegung wäre beispielsweise ohne entsprechende Gesetze zur Gleichstellung
mit der gedruckten Rechnung nicht möglich gewesen. Zhu et al. finden heraus, dass
der regulative Rahmen vor allem in Entwicklungsländern eine signifikante Rolle
spielt272. Berthon et al. machen zusätzlich auf den Einfluss transnationaler Aspekte
bei internationalen elektronischen Geschäftsbeziehungen aufmerksam. Diese ergeben sich vor allem aufgrund Unterschiede in den kulturellen Werten und der technologischen Infrastruktur des jeweiligen Landes273.
3.3 Relevante konzeptuelle Ansätze und Rahmenwerke auf
unterschiedlichen Ebenen im Detail
Zur fundierten Erschließung des Forschungskontextes werden im Folgenden noch
ausgewählte Rahmenwerke und konzeptuelle Architekturmodelle zur betrieblichen
Integration diskutiert. Das Ziel dieses Kapitels ist es, einen Überblick über anerkannte und relevante Ansätze aus der Literatur zu geben, um daran anschließend einer
vergleichenden Analyse zu unterziehen und einen Bezugsrahmen für die gegenständliche Arbeit herzustellen.
Die Grundmotivation für betriebliche Integration ist die Verbesserung und Optimierung; die Optimierung von Prozessen durch das Schließen von Lücken zwischen
Systemen, die Automatisierung und Beseitigung von Medienbrüchen und Fehlern
durch Technologien, die Bereitstellung von Dienstleistungen zur Steigerung des
Kundenservice, usw.274. Diese Beispiele zeigen, dass bei einer betrieblichen Integration unterschiedliche Ebenen betroffen sind. Eine Identifikation und Strukturierung
dieser konzeptuellen Ebenen wird in den nachfolgend diskutierten Ansätzen vorgenommen.
271
272
Vgl. Zhu et al. (2003, S. 9)
273
Vgl. Berthon et al. (2008, S. 84)
274
Vgl. Herzog (2006, S. 31)
59
3.3.1 Das Dreiebenenmodell des Business Networking
Nach Alt und Fleisch versucht das Business Networking „Prozesseffizienzen, Kundenbindung und/oder neue Geschäftspotentiale durch die innovative Gestaltung von
Kunden-/Lieferantenbeziehungen herzustellen“.275 Das Dreiebenenmodell des Business Networking beschreibt demzufolge die Strukturierung und Darstellung von
Problemstellungen und Lösungen der Vernetzung und stellt die grundlegenden
Abhängigkeiten auf den Ebenen Geschäftsstrategie, Geschäftsprozess und Informationssystem dar. Auf der Basis der Ebenen des Business Engineering nach Österle276 entwerfen die Autoren das Bild des Netzwerkunternehmens, in dem die Prozesse die Bindeglieder von Geschäftsstrategien mit den neuen Informationssystemen
sind. Prozesse (bzw. Prozessnetzwerke) basieren auf Informationssystemen, welche
die Basis aller operativen Netzwerke im Informationszeitalter bilden und setzen
Geschäftsstrategien zur Vernetzung um (siehe Abbildung 8).
Abbildung 8: Vernetzung auf den drei Ebenen des Business Engineering im Business Networking277
Die Strategieebene umfasst formelle und informelle Kooperationsbeziehungen
zwischen den beteiligten Unternehmen. Unter formellen Kooperationsbeziehungen
verstehen die Autoren Rahmenverträge, gegenseitige Beteiligungen oder Verflechtungen in der Wertschöpfung. Vertrauen zwischen Partnerunternehmen und gemeinsam getragene Normen und Werte sind Beispiele für informelle Kooperationsbezie-
275
Alt und Fleisch (2003, S. 356)
276
Vgl. Österle (1995, S. 16–18)
277
60
hungen. Unternehmen und Kooperationsbeziehungen bilden gemeinsam ein Geschäftsnetzwerk278.
Die Prozessebene betrifft die Gestaltung der Prozessnetzwerke. „Ein Prozessnetzwerk ist ein geschäftseinheitsübergreifender Verbund von Geschäftsprozessen, der
eine Kooperationsstrategie auf operativer Ebene realisiert und Kundenprozessen
Leistungen zur Verfügung stellt.“279 Die Koordination zwischen den Prozessen sorgt
dabei für die Abstimmung der Leistungserstellung (z.B. Wann und wie häufig sind
welche Planungsdaten auszutauschen).
Die Informationssystemebene konzentriert sich auf Informationssystemnetzwerke,
welche die Prozessnetzwerke unterstützen. Ein Informationssystemnetzwerk besteht
einerseits aus Applikationen und Daten sowie andererseits aus Kommunikationsverbindungen zum Zwecke der Systemintegration wie z.B. Sprachverbindungen via
Telefon oder Austausch von EDI Nachrichten280.
Das Dreiebenenmodell beschreibt primär die fachliche Dimension des Business
Networking. Die Netzwerkfähigkeit wird von den Autoren als Wettbewerbsfaktor
gesehen. Das Ziel des Business Networking ist demnach die Steigerung der Wettbewerbsfähigkeit über eine höhere Netzwerkfähigkeit. Die Netzwerkfähigkeit eines
Unternehmens definieren die Autoren als „interne und externe Kooperationsfähigkeit
sowie die Fähigkeit zur schnellen und effizienten Bildung, Durchführung und Weiterentwicklung von IT-gestützten Geschäftsbeziehungen.“281
Zur Gestaltung und Umsetzung der Netzwerkfähigkeit stehen dem Unternehmen die
Gestaltungsobjekte bzw. -elemente Leistung, Prozess, IKT, Mensch, Unternehmenskultur und Organisationsstruktur zur Verfügung. Mit netzwerkfähigen Produkten und
Dienstleistungen können schnell und kostengünstig partnerspezifische Anpassungen
durchgeführt oder zusätzliche Leistungen integriert werden. Netzwerkfähige Prozesse lassen sich effizient und effektiv mit korrespondierenden Prozessen der Netzwerkpartner koordinieren. Eine netzwerkfähige Informations- und Kommunikationstechnologie (IKT) ermöglicht eine effiziente und effektive Kopplung von Informationssystemen und netzwerkfähige Mitarbeiter sind unerlässlich für den Aufbau und
die Pflege von persönlichen Partnerbeziehungen. Eine netzwerkfähige Organisationsstruktur kann schnell und kostengünstig auf neue Marktanforderungen (z.B.
durch die Bildung unternehmensübergreifender Teams, durch das Auslagern von
278
Vgl. Fleisch (2001, S. 281)
279
Fleisch (2001, S. 281)
280
Vgl. Fleisch (2001, S. 281)
281
61
Geschäftsprozessen, etc.) reagieren und eine netzwerkfähige Unternehmenskultur
fördert die Zusammenarbeit durch Offenheit für Veränderungen und gegenseitiges
Vertrauen der Netzwerkpartner282.
Das Dreiebenenmodell des Business Networking rückt die Prozesse in den Mittelpunkt (dh. der Ansatz baut primär auf der Prozesssicht auf), berücksichtigt aber auch
neben der technischen Vernetzung von Unternehmen weitere Gestaltungsobjekte,
welche zur Steigerung der Netzwerkfähigkeit des Unternehmens beitragen.
3.3.2 Integration heterogener Informationssysteme
Die Verwendung von heterogenen, oft autonomen Informationssystemen führt zu
einer vertikalen Fragmentierung über Unternehmensgrenzen hinweg. Nach Hasselbring betrifft diese Fragmentierung einzelne Organisationseinheiten („Organisational
Units“). Die Daten der Organisationseinheiten liegen in unterschiedlichen Informationssystemen mehrfach vor, was eine Integration erschwert. Konzeptuell wird jede
Einheit in eine Geschäftsarchitektur, Anwendungsarchitektur und Technologiearchitektur strukturiert. Deswegen müssen diese Organisationseinheiten horizontal auf
drei Ebenen integriert werden:

Zwischenbetriebliche Prozesse: Auf dieser Ebene werden Geschäftsprozesse zwischen den Organisationseinheiten integriert. Dabei unterliegen die
Geschäftsprozesse einem kontinuierlichen Wandel.

Enterprise Application Integration (EAI): Das Ziel dieser Ebene ist es, unabhängige ERP Systeme zu integrieren. Dies erfordert meist auch eine Änderung der Geschäftsprozesse. Zusätzlich wird darauf hingewiesen, dass Datenformate der verschiedenen Systeme verstanden werden müssen. Dies erfordert die Verwendung von XML- oder EDI-basierten Standards zur Integration.

Middleware: Diese Ebene befasst sich mit dem technologischen Aufbau einer
State-of-the-art Infrastruktur zur Integration. Der Übergang zwischen EAI und
Middleware ist fließend, wobei die Middleware Ebene eher die syntaktische
Ebene adressiert und EAI auch Informationen auf semantischer Ebene beinhaltet.
Abbildung 9 verdeutlicht den Aufbau der vertikalen Integration über Organisationseinheiten und der horizontalen Integration heterogener Informationssysteme zur
Unterstützung von zwischenbetrieblichen Prozessen.
282
Vgl. Alt und Fleisch (2003, S. 357)
62
Abbildung 9: Integration heterogener Informationssysteme zur Unterstützung der Prozesse283
3.3.3 „EAI Integration Layers”
Die Autoren Themistocleous et al.284 widmen sich in ihrer Forschung dem Thema der
Enterprise Application Integration (EAI). Die Verwendung von EAI Software adressiert die Notwendigkeit der effektiven Integration von intra- und interorganisationalen
Systemen. EAI wird also nicht nur zur innerbetrieblichen Integration von Informationssystemen (z.B. ERP System) gesehen, sondern ebenso zur zwischenbetrieblichen Integration (z.B. SCM System)285. Bei der technischen Kopplung von zwei
unterschiedlichen Informationssystemen mittels EAI Software sind drei Ebenen der
Integration betroffen:

Transportebene („Transportation“): Die auszutauschenden Informationen
werden über die Transportebene von der Quell-Applikation zur Ziel-Applikation
übertragen.

Übersetzungsebene („Translation“): Die Informationen werden von ihrem
Ausgangsformat in das gewünschte Zielformat übersetzt.
Prozessebene („Process Automation“): Auf dieser Ebene wird die automatische
Ausführung von Geschäftsprozessen sichergestellt. Diese Ebene fungiert auch als
Trigger für Ereignisse, die aufgrund von Geschäftsregeln, Services oder Nebenbedingungen eintreten können. Abbildung 10 zeigt wie die Integration einer QuellApplikation mit einer Ziel-Applikation auf diesen drei Ebenen der Integration mittels
EAI durchgeführt wird. Die Gestaltungselemente der Integration sind Daten, Objekte
und Prozesse, welche auf den drei Ebenen der Integration manipuliert werden.
283
Hasselbring (2000, S. 35)
284
Vgl. Themistocleous et al. (2002); Themistocleous und Irani (2003)
285
Vgl. Diskussion zum zwischenbetrieblichen Einsatz von EAI Technologien in der Einleitung (Kapitel
1).
63
Abbildung 10: "EAI Integration Layers"286
3.3.4 „B2B Reference Framework“
Kajan287 analysiert den State-of-the-art und Trends offener Technologien zur Herstellung einer „vollständigen“ B2B Interoperabilität für Unternehmen jeglicher Größe und
Branche. Ein System ist ein offenes System, wenn es die drei Eigenschaften Portabilität, Skalierbarkeit und Interoperabilität (PSI) erfüllt und aus Software- oder Hardware-Komponenten besteht, welche auf weitverbreiteten, akzeptierten (de facto oder
de jure) Standards beruhen. Die Portabilität bezieht sich auf die Übertragbarkeit des
Quellcodes auf verschiedene Hardware-Plattformen, Skalierbarkeit meint die Anpassbarkeit der Software-Applikation auf verschiedene Hardwareressourcen und
Interoperabilität bezeichnet die Kommunikation zwischen geografisch getrennten,
heterogenen Systemen. Eine Offenheit, wie sie im OSI-Modell288 bereits Mitte der
1980er Jahre erstmals vorgeschlagen wurde, konnte trotz dessen wichtiger Pionierarbeit bis dato nicht erreicht werden. Für den teilweisen Misserfolg des OSI-Modells
verantwortlich zeigen sich schlechtes Timing, schlechte Technologien, schlechte
Implementierungen und schlechte Politik. Der elektronische Datenaustausch via EDI,
ausgerichtet auf eine Minimierung von Kosten, Aufwand und Zeit, setzte sich aus den
gleichen Gründen ebenfalls nicht flächendeckend durch. Große Unternehmen haben
in die Implementierung ihrer EDI-Lösungen investiert und hatten am Ende trotzdem
keine Möglichkeit zur elektronischen Abwicklung ihrer Geschäfte, da vor allem KMUs
EDI nicht einsetzten.
286
Themistocleous et al. (2002, S. 1090)
287
Vgl. Kajan (2004)
288
ISO/IEC 7498-1:1994
64
Aus den Erfahrungen und Misserfolgen der Vergangenheit schließt der Autor, dass
sich ein schwergewichtiger, monolithischer und globaler „Super-Standard“ für B2B
Integration nicht durchsetzen wird. Stattdessen muss eine Lösung eine Win-WinSituation für alle Teilnehmer erzeugen sowie offen und skalierbar sein, sodass Unternehmen jeglicher Größenordnung und Branche daran partizipieren können. Ein
allgemeines Framework enthält verfügbare, offene Standards, relevante Technologien und Systeme zur B2B Integration. Das vorgeschlagene Framework (siehe
Abbildung 11) zeigt die benötigte, komponentenorientierte Architektur, um heterogene und verteilte Systeme zu koppeln und B2B Interoperabilität herzustellen.
Abbildung 11: B2B Reference Framework289
Die Basis eines B2B Rahmenwerks bildet innerhalb des Unternehmens eine nach
dem „ZLE-Ansatz“ (Zero Latency Enterprise) optimierte Architektur. Mit „Zero Latency
Enterprise“ beschreiben die Marktforscher von Gartner290 eine IT-Infrastruktur, in der
Daten aus allen Bereichen in Echtzeit zum Nutzen des Unternehmens verwendet
werden können. In einem solchen Unternehmen sind die Informationssysteme und
Geschäftsprozesse nahtlos integriert. Das B2B Framework enthält dementsprechend
einen mehrschichtigen Aufbau, basierend auf: Client, Web- bzw. Applikationsserver
289
290
Kajan (2004, S. 38)
URL: http://www.gartner.com/it-glossary/zle-zero-latency-enterprise/, IT Glossary, Gartner Inc.
[2.1.2013]
65
(AS) und Datenbank Server (DB). Die darüber liegenden Schichten stellen eine
plattformunabhängige Ausführung von Anwendungsprogrammen zur B2B Integration
sicher. Die Laufzeitumgebung besteht aus der Hardware-, Betriebssystem- und
Protokoll-Schicht. Die Hardware-Schicht umfasst Mikroprozessoren von verschiedenen Herstellern (Intel, IBM, AMD, etc.). Auf der Betriebssystem-Schicht dominieren
UNIX, Linux und Windows, welche das TCP/IP-Protokoll zur Kommunikation verwenden. Basierend auf dem TCP/IP-Protokoll bieten jüngere Protokolle wie SOAP291
(Simple Object Access Protocol) oder BEEP292 (Blocks Extensible Exchange Protocol) zusätzliche Services zur B2B Kommunikation. Die B2B Middleware Schicht hat
die Aufgabe Homogenität zwischen den darunterliegenden Schichten und den verschiedenen Applikationen herzustellen. Dazu stellt die Middleware Services für
verteilte Dateisysteme, Naming, Messaging und Ressourcen-Sharing zur Verfügung.
Beispiele für die „Underlying Middleware“ sind etwa der Verzeichnisdienst LDAP293
(Lightweight Directory Access Protocol) oder verschiedene RPC (Remote Procedure
Call) Implementierungen, da diese – obwohl nicht speziell für B2B entwickelt – in der
B2B Umgebung eingesetzt werden können.
In einer B2B Umgebung müssen die Ebene der Geschäftsprozesse und die Ebene
des Datenaustausches spezielle Berücksichtigung finden. Auf der Datenebene
werden sowohl Struktur und Semantik der Daten als auch die Transportprotokolle
festgelegt. Im Gegensatz zur Datenebene, wo sich die Partner auf geeignete Datenformate und –modelle einigen sollten, beschäftigen sie sich auf Geschäftsprozessebene mit interaktivem, kollaborativem Austausch von Nachrichten. Web Services
eignen sich zur Umsetzung von B2B auf diesen Ebenen. Der Autor nennt hierbei
unter anderem WSDL294 (Web Services Description Language) auf Datenebene und
WS-BPEL295 (Web Services Business Process Execution Language) auf Geschäftsprozessebene als etablierte Standards. Den nächsten Schritt in der B2B Integration
stellt die Entwicklung intelligenter, semantischer Frameworks auf der Basis von Web
Services dar. Das WSMF296 (Web Service Modeling Framework) erlaubt hierzu die
Definition von spezialisierten Ontologien zur Ermöglichung eines semantischen
Austausches von Informationen über P2P Netzwerke, welche von allen Unternehmen
291
URL: http://www.w3.org/TR/soap12/, W3C: Simple Object Access Protocol (SOAP Version 1.2)
[2.1.2009]
292
URL: http://www.rfc-editor.org/rfc/rfc3080.txt, RFC3080: The Blocks Extensible Exchange Protocol
Core. 2001 [2.1.2009]
293
URL: http://www.rfc-editor.org/rfc/rfc2251.txt, RFC2251: Lightweight Directory Access Protocol (v3)
1997 [2.1.2009]
294
URL: http://www.w3.org/TR/wsdl, W3C: Web Services Description Language (WSDL Version 1.1)
[5.1.2009]
295
URL: http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html, OASIS: Web Services Business
Process Execution Language (WS-BPEL Version 2.0) [5.1.2009]
296
Vgl. Fensel und Bussler (2002); Bussler et al. (2002, S. 26)
66
verstanden werden und es allen Partnern erlaubt, automatische Geschäftstransaktionen durchzuführen, egal wie unterschiedlich diese sind.
3.3.5 „Collaborative Business Process Management“
Die Autoren Adam et al. sehen die unternehmensübergreifende Zusammenarbeit als
überlebenskritisches Instrument für Unternehmen, um den Auswirkungen der Globalisierung und der zunehmenden Umweltdynamik begegnen zu können.297 Zum Management unternehmensübergreifender Geschäftsprozesse entwerfen die Autoren
das Collaborative Business („C-Business“) Process Management Rahmenwerk,
welches folgende konzeptuelle Ebenen beinhaltet298:

C-Business Strategie: Die oberste Ebene betrachtet die Strategie zur zwischenbetrieblichen Kollaboration.

C-Business Process Engineering: Auf dieser Ebene werden Entwurf, Optimierung und Controlling sowohl der unternehmensübergreifenden als auch
der zugehörigen internen Prozesse vorgenommen.

C-Business Execution: Die unterste Ebene fokussiert auf die operative Ausführung der Geschäftsprozesse im Wertschöpfungsnetzwerk sowie deren Unterstützung durch Informations- und Kommunikationstechnologie.
Abbildung 12 veranschaulicht den Aufbau des Dreiebenenmodells. Es zeigt zusätzlich die Unterteilung in eine vertikale Achse globalen Wissens aller Kollaborationspartner und eine horizontale Achse lokalen Wissens der einzelnen Teilnehmer.
297
Vgl. Adam et al. (2004, S. 537)
298
Vgl. Adam et al. (2004, S. 538)
67
Abbildung 12: Rahmenwerk für das kollaborative Geschäftsprozessmanagement299
Die Autoren betonen die Wichtigkeit des globalen Netzwerkwissens in der Form von
Organisations- und Leistungssicht, da ohne dieses Wissen eine zielgerichtete Kollaboration nicht möglich ist. Änderungen wie der Austritt eines Partners aus dem
Netzwerk (Organisationssicht) oder Abweichungen in der Verfügbarkeit von Produkten (Leistungssicht) müssen allen Partnern unmittelbar zugänglich gemacht werden.
Anders verhält es sich mit der Daten- sowie Funktionssicht; diese werden aus lokaler
Perspektive, also aus Sicht eines jeden Unternehmens, betrachtet, da hier in dem
jeweiligen Unternehmen die notwendigen Detailfunktionen und Datenschemata
festgelegt werden. Ausgetauscht werden Definitionen zu den Schnittstellen der
Daten- und Funktionssicht. Diese betreffen vor allem den technologischen Bereich
der Kooperation bei der Durchführung. Globales Netzwerkwissen und lokales Anwendungswissen treffen in der Prozesssicht aufeinander300.
3.3.6 Rahmenwerk zur IOS-Adoption
Pang und Bunker gehen der Frage nach, was zwei Organisationen bei der Einführung eines Interorganisationalen Informationssystems (IOS) zum Management der
Wertschöpfungskette mit sich bringen müssen. Die Autoren stellen zur Beantwortung
dieser Fragestellung ein theoretisch fundiertes Rahmenwerk zur betrieblichen Kollaboration auf, das folgende drei Ebenen aus der Perspektive des Kunden sowie des
Lieferanten behandelt301:
299
Adam et al. (2004, S. 538)
300
Vgl. Adam et al. (2004, S. 539)
301
Vgl. Pang und Bunker (2007)
68

Strategie: Im Mittelpunkt dieser Ebene der Kollaboration steht das Top Management beider Parteien. Diese diskutieren und entwickeln eine gemeinsame
Strategie, die beide Parteien zufrieden stellt.

Prozess: Auf dieser Ebene arbeitet das zuständige Management (wie die Abteilungen Logistik, Planung, Produktion und Lagerhaltung) an der Verbesserung und Weiterentwicklung der gemeinsamen Geschäftsprozesse der Wertschöpfungskette. Dafür müssen auch die innerbetrieblichen Prozesse angepasst werden. Inner-, über- und zwischenbetriebliche Prozessverbesserungen
werden daher simultan und kontinuierlich durchgeführt.

Technik: Die technische Ebene beinhaltet die Implementierung des IOS. Auf
dieser Ebene sind die IT-Abteilungen in Absprache mit dem ProzessManagement der beiden Parteien involviert.
Der Aufbau des Rahmenwerks wird in Abbildung 13 verdeutlicht.
Abbildung 13: Rahmenwerk zur IOS-Adoption in Wertschöpfungsketten302
3.3.7 Die „Integrated Vision for Electronic B2B-Collaboration”
Norta303 beschreibt automatisierte B2B Integrationen als komplexe, offene, dynamische Systeme mit breitem Kontext, welche neben technisch-funktionalen auch nichtfunktionale Anforderungen wie Vertrauen, Risiko, Privatsphäre und Reputation beinhalten. Diese Komplexität soll in einem integrierten Rahmenwerk für B2B Kollaborationen bewältigt werden. Abbildung 14 zeigt diese konzeptuelle Vision, welche das
„Dynamic Inter-Organizational Business Process Management“ (DIBPM) Rahmenwerk von Norta et al.304 um die Dimensionen Lebenszyklus, eCommunity und die
Ebenen der Semiotik (Pragmatik, Semantik und Syntax) erweitert.
302
Pang und Bunker (2007, S. 5)
303
Vgl. Norta (2007)
304
Vgl. Norta et al. (2006)
69
Abbildung 14: Integrated Vision for Electronic B2B-Collaboration305
Der Ansatz des DIBPM zur betrieblichen Integration basiert auf einer Kopplung von
Geschäftsprozessen mit serviceorientierten Technologien und wird folgendermaßen
definiert:
“A dynamic inter-organizational business process is formed dynamically by the (automatic) integration of the subprocesses of the involved organizations. Here dynamically means
that during process enactment collaborator organizations are found by searching business
process market places and the subprocesses are integrated with the running process.”306
Die Integration von unternehmensübergreifenden Geschäftsprozessen wird innerhalb
von DIBPM mit dem Konzept des eSourcing beschrieben. eSourcing zielt auf eine
strukturelle Harmonisierung von unternehmensübergreifenden Geschäftsprozessen
zwischen Services konsumierenden und Services bereitstellenden Partnern ab und
beschreibt Prozesse anhand drei Ebenen. Die interne Ebene beschreibt Prozesse
als direkt im System (z.B. WFMS) des Unternehmens ausführbare Prozesse. Unternehmensintern werden die Prozesse zusätzlich auf der konzeptuellen Ebene, dh.
unabhängig von der vorhandenen Infrastruktur und Art der Kollaboration, beschrieben. Die externe Ebene spannt schlussendlich die Prozesse auf die unternehmensübergreifende Ebene, wo der strukturelle Abgleich vollzogen wird. Dabei werden nur
jene Teile der Prozesse auf der externen Ebene abgebildet, die für die automatisierte, dynamische Kollaboration zwischen den Partnern erforderlich sind.
305
Norta (2007, S. 3)
306
Norta et al. (2006, S. 836)
70
Zur Bewältigung der Komplexität überbetrieblicher Kollaborationen erweitert der
Autor das Rahmenwerk um drei zusätzliche Dimensionen. Eine Dimension beschreibt den Lebenszyklus einer automatischen B2B Kollaboration mit den Phasen
„setup“, „enactment“ und „post-enactment“. Während der Setup-Phase kommt es
durch Vertragsverhandlungen zur Bildung einer elektronischen Community („eCommunity“), welche die nicht-funktionalen Anforderungen abdeckt. Veränderungen der
Community durch Hinzunahme neuer bzw. Wegfall von Partnern resultieren in einem
neuen Status der eCommunity, welche in einer separaten Dimension dargestellt wird.
Die dritte Dimension beschreibt Kollaborationen mit den Begriffen Pragmatik, Semantik und Syntax. Pragmatische Kollaboration meint die generelle Bereitschaft der
Partner zur überbetrieblichen Integration und zur Durchführung der dafür notwendigen Tätigkeiten. Die semantische Kollaboration stellt sicher, dass eine Nachricht vom
Sender und Empfänger in gleicher Weise interpretiert und verstanden wird und
syntaktische Kollaboration bedeutet, dass Nachrichten von einer Anwendung zu
einer anderen Anwendung transportiert und korrekt ausgeführt werden können.
Während DIBPM inkl. dem Konzept des eSourcing in Fallstudien und Prototypen im
Zuge des EU Projekts CrossWork307 bereits angewandt und evaluiert wurde, handelt
es sich bei dessen Erweiterungen um die zusätzlichen Dimensionen um einen aus
wissenschaftlicher Literatur abgeleitete Vision ohne Evaluation.
307
URL: http://www.crosswork.info, Projekt CrossWork: Cross-Organisational Workflow Formation and
Enactment, EU FP6, 2004-2007, IST-507590 [7.1.2009]
71
3.3.8 Das „Three-level framework for Modeling B2B Applications”
Maamar et al.308 stellen ein Rahmenwerk für die Modellierung und den Einsatz von
B2B Applikationen mittels Web Services vor. Das Rahmenwerk enthält die drei
Ebenen Ressourcen, Applikationen und Strategie, welche sowohl vertikale als
auch horizontale Beziehungen aufweisen (siehe Abbildung 15).
Abbildung 15: Das “Three-level framework for Modeling B2B Applications”309
Die Ebene der Ressourcen wird in den logischen und physischen Teil gegliedert.
Der logische Teil enthält jene Daten, welche für die Ausführung der täglichen Geschäftstätigkeit benötigt werden. Zusätzlich werden für die Software benötigte Betriebssystem, Datenbankmanagementsystem (DBMS) etc. im logischen Teil subsumiert. Unter dem physischen Teil der Ressourcen verstehen die Autoren die Hardware, welche für den Betrieb der Software und den Austausch der Daten benötigt
wird (z.B. Server, Router, usw.).
Die Ebene der Applikationen setzt auf die Ebene der Ressourcen auf und umfasst
Softwareanwendungen. Diese Softwareanwendungen können allgemeine Anwendungen wie Textverarbeitung und Tabellenkalkulation oder spezielle Software zum
Supply Chain Management, Tracking von Lieferungen usw. sein. Softwareanwendungen verwenden logische und physische Ressourcen zur Verrichtung ihrer regulären Tätigkeiten wie Datenmanagement, Datentransfer, oder Datenzugriffskontrolle.
Die Strategieebene umfasst alle Planungs- und Steuerungsmaßnahmen für Entscheidungsträger zur Erreichung ihrer Geschäftsziele. Auf der Strategieebene werden die dafür benötigten Informationen aggregiert dargestellt, um eine vollständige
Sicht auf die Daten zu gewährleisten.
308
Vgl. Maamar et al. (2008)
309
Maamar et al. (2008, S. 12)
72
Die drei Ebenen weisen sowohl vertikale als auch horizontale Verbindungen auf. Die
vertikale Beziehung beschreibt die Verbindung der verschiedenen Ebenen innerhalb
eines Unternehmens mittels „rely-on“ und „deployed-on-top-of“ Beziehungen. In einer
B2B Umgebung liegt aber der Fokus auf der Beziehung zwischen Unternehmen,
welche im Framework durch die horizontale Verbindung zwischen gleichen Ebenen
unterschiedlicher Unternehmen beschrieben wird. Die Konnektivität („Interconnectivity“) auf der Ebene der Ressourcen ermöglicht einen ungehinderten und sicheren
Datenfluss zwischen Unternehmen über Schnittstellen. Probleme auf dieser Ebene
können durch inkompatible Kommunikationsprotokolle oder nicht erreichbare Hardware hervorgerufen werden. Die horizontale Beziehung auf der Ebene der Applikationen wird im Framework mit der Ausführungsfolge („Composition“) beschrieben. Die
Ausführungsfolge beschreibt wie die betroffenen Geschäftsprozesse mittels Softwareapplikationen über Unternehmensgrenzen hinweg integriert werden können. Die
Autoren empfehlen für diese Integration die Verwendung von Web Services. Probleme auf der horizontalen Ebene treten dann auf, wenn die benötigte Funktionalität von
der Applikation nicht zur Verfügung gestellt oder die ausgetauschte Information von
einer Applikation semantisch nicht korrekt interpretiert wird. Auf strategischer Ebene
wird die horizontale Beziehung als Kollaboration („Collaboration“) bezeichnet. Kollaboration beschreibt alle Mechanismen, welche zur Zusammenarbeit und Koordination
der neu geschaffenen B2B Prozesse benötigt werden. Dabei müssen die Anforderungen und Einschränkungen der Ebenen der Ressourcen und Applikationen der
kooperierenden Unternehmen berücksichtigt werden. Konflikte können beispielsweise durch eine gegensätzliche Unternehmenspolitik und einem Fehlen an Konsens
auf Geschäftsebene entstehen.
3.3.9 Der „Social Collaboration Layer“
Die Verwendung von Web 2.0 Technologien hat in den letzten Jahren in Unternehmen Einzug gehalten. Um das Nutzenpotential dieser Technologien zur Kollaboration
auszuschöpfen, sollten sich Unternehmen auch im Zuge der Unternehmens- und
Informationsarchitektur damit beschäftigen. In einem Diskussionspapier führt Clement dazu den Begriff „Social Collaboration Layer“ ein310.
Die konzeptuelle Betrachtung der sozialen Ebene in der Unternehmensarchitektur
ermöglicht es, sich mit Fragen der Sicherheit, Authentifizierung, Autorisierung und
Auslieferung der Inhalte an unterschiedliche Kanäle gezielt auseinanderzusetzen. So
können Web 2.0 Technologien im Unternehmenskontext betrachtet und mit serviceorientierter Architektur verbunden werden. Das Wichtigste dabei ist, dass dadurch
310
Vgl. Clement (2008)
73
relevante Informationen in einer Ebene gebündelt und durch den Endanwender, den
Wissensarbeiter, geräteunabhängig konsumiert werden können311.
Aus Architektursicht liegt der „Social Collaboration Layer“ unterhalb der Präsentationsschicht und oberhalb des sogenannten „Enterprise Service Bus“ (ESB), der
Prozesse, Dienste und Web Services der verschiedenen Informationssysteme wie
SAP, Siebel oder Oracle verbindet und so eine serviceorientierte Architektur ermöglicht (siehe Abbildung 16).
Abbildung 16: „Social Collaboration Layer“312
3.4 Integrationsebenen: Vergleichende Betrachtung der Ebenen konzeptueller Ansätze und Rahmenwerke
Das Ergebnis einer Literaturrecherche in Kapitel 3.3 zeigte, dass kein einheitliches
Verständnis über die entsprechenden Ebenen bei betrieblichen Integrationen aus
konzeptueller Sicht vorhanden ist. Die Autoren haben eine unterschiedliche Auffassung von Ebenen und demensprechend konzentrieren sich bestehende Ansätze auf
unterschiedliche Gesichtspunkte der Unternehmens- und Informationsarchitektur.
Eine vergleichende Betrachtung der Modelle und Rahmenwerke ist daher sinnvoll
und notwendig.
311
Vgl. Clement (2008, S. 3); Polaschek et al. (2012, S. 4–5)
312
Clement (2008, S. 3)
74
Abbildung 17 stellt den Vergleich im Überblick dar. Sie zeigt die betrachteten konzeptuellen Ansätze und die betroffenen Integrationsebenen. Ferner wird die Behandlung
von Gesichtspunkten der drei Integrationsdimensionen Technologie, Organisation
und Umfeld sowie die Ausrichtung an einer Strategie zur Integration beurteilt. Ein
gefüllter Kreis zeigt an, dass die spezifische Ebene bzw. Dimension im Ansatz explizit und umfassend berücksichtigt wird; ein nicht gefüllter Kreis das Gegenteil. Ein
halb gefüllter Kreis bedeutet, dass die Ebene bzw. Dimension zwar adressiert wird,
jedoch nicht explizit im Modell (z.B. als Ebene) aufscheint oder nur am Rande erwähnt wird.
Abbildung 17: Vergleich konzeptueller Ansätze zur betrieblichen Integration (eigene Darstellung)
Betriebliche Integrationen sind als Innovationen zu sehen und nach der Argumentation in Kapitel 3.2 unter Berücksichtigung der Dimensionen Technologie, Organisation und betriebliches Umfeld zu bewerten. Eine holistische Betrachtung der Thematik muss folglich diese drei Kontexte beinhalten. Der Vergleich zeigt allerdings, dass
keine der Ansätze alle drei Integrationsdimensionen vollständig abdecken. Wenn die
technische Dimension in allen Ansätzen zumindest teilweise und die organisatorische
Dimension noch in sieben der neun Ansätze adressiert werden, so wird das betriebliche Umfeld nur in zwei Ansätzen angesprochen.
Nicht alle Projekte in der Praxis entstehen aus einer strategischen Vision. In der
Literatur wird jedoch die strategische Ausrichtung von Projekten als bedeutendes
Thema diskutiert313. Auch in den meisten Ansätzen wird die Orientierung an einer
Strategie als wichtig hervorgehoben und in vier Ansätzen explizit als Ebene modelliert. In der gegenständlichen Arbeit ist die Strategie daher ebenso zu adressieren,
313
Vgl. Zwikael und Smyrk (2011, S. 1); Österle (1995, S. 24); Wang et al. (2008, S. 148); Harland et
al. (2007, S. 1235)
75
jedoch nicht als Integrationsebene. Integrationsebenen werden verwendet, um
Konzepte von Integrationslösungen einordnen und Szenarien aus der Praxis beschreiben zu können. Das Vorhandensein einer ganzheitlichen, zielgerichteten und
strategischen Sichtweise zur betrieblichen Integration wird in diesem Fall als eine
bedeutsame Voraussetzung für die Realisierung von Integrationslösungen gesehen314. Diese ist daher vor der Durchführung einer Integration zu adressieren. Eine
betriebliche Integration sollte strategisch geleitet sein, um den Anforderungen von
internen und externen Stakeholder gerecht zu werden. Dies schließt standortübergreifend agierende Abteilungen genauso ein wie Lieferanten und Kunden im Wertschöpfungsnetzwerk, aber auch die Unterstützung des eigenen Top Managements.
Die Strategie spielt in allen Integrationsebenen eine Rolle, zielt auf die Integration
bestimmter Stakeholder ab und wird aus diesem Grund nicht als Integrationsebene
bezeichnet.
Aufgrund der Vielfältigkeit von betrieblichen Integrationen ist es zusätzlich sinnvoll,
die betroffenen Ebenen einer Integration nach einer einheitlichen Einteilung zu
beschreiben. Aus der Literaturrecherche und im Quervergleich der Ansätze zeigen
sich nun fünf dominante konzeptuelle Ebenen, die von einer betrieblichen Integration betroffen sein können:
314

Integration auf Ebene der Daten: Die Integration auf der Datenebene schafft
meist die technischen Voraussetzungen für eine betriebliche Integration auf
weiteren Ebenen und wird daher auch in allen Ansätzen angeführt.

Integration auf Ebene der betrieblichen Informationssysteme: Betriebliche
Informationssysteme verwalten die Datenbasis, transformieren diese zu Informationen und binden dabei Geschäftsprozesse ein. Die Ebene der betrieblichen Informationssysteme ist daher ebenso essentiell für betriebliche Integrationslösungen, wie die Datenintegration und wird auch in allen betrachteten
Ansätzen berücksichtigt.

Einsatz von dedizierter Software als „Middleware“ zur Integration: Nur zwei
Ansätze befassen sich umfassend mit Middleware zur betrieblichen Integration
und in fünf Ansätzen wird diese nicht erwähnt. Für den Nutzer meist transparent, tritt Middleware als Zwischenschicht zwischen verschiedenen, heterogenen Systemen auf und ermöglicht so die Kommunikation zwischen diesen
Systemen.

Integration auf der sozialen Ebene: Zurückzuführen auf die noch junge Vergangenheit kollaborativ-sozialer Integrationslösungen, weisen konzeptuelle
Ansätze noch eine Lücke auf dieser Ebene auf. So beschäftigt sich nur ein
Vgl. Vernadat (2007, S. 137); Kühn und Karagiannis (2005, S. 1483)
76
Ansatz umfassend mit der Definition einer Ebene zur sozialen Kollaboration
(„Social Collaboration Layer“).

Integration auf Ebene der Prozesse und Services: In den meisten Ansätzen
wird klar hervorgehoben, dass einer der wichtigsten Voraussetzungen für eine
betriebliche Integration eine Kompatibilität auf Geschäftsprozessebene ist.
Dementsprechend findet die Ebene der Prozesse und Services auch in allen
Ansätzen zumindest Erwähnung.
Die identifizierten konzeptuellen Integrationsebenen werden in den nachfolgenden
Kapiteln näher beschrieben.
3.4.1 Integration auf Ebene der Daten
Unter der Datenintegration versteht man das Entnehmen von Daten aus einem
persistenten Datenspeicher (wie einer Datenbank) und deren strukturierten Überführung in einen anderen. Dies kann bereits ein sehr komplexer Vorgang sein, da die
handelnden Personen neben den Datenbanktechnologien auch den Fluss der Daten
durch das Unternehmen verstehen müssen315. Die strukturelle Heterogenität der
Daten erschweren den Austausch zusätzlich316. Neben der Übermittlung der Daten
ist daher die Transformation derselben eine der Hauptaufgaben einer Integrationslösung auf Datenebene317. Wenn Unternehmen nicht die gleiche Sprache sprechen,
können auch keine Daten elektronisch ausgetauscht werden. Um den Abstimmungsaufwand bei der Datenintegration zu minimieren, ist es daher notwendig, allgemein
akzeptierte Standards für den elektronischen Austausch von Informationen zu entwickeln und einzusetzen. Dies haben sowohl Forschung als auch Unternehmen gleichermaßen erkannt318. Speziell die Forderung von mittleren und vor allem großen
Unternehmen nach international gültigen Standards wird immer größer319. Das Problem ist allerdings, dass es zu viele Standards gibt, sehr viele davon noch in Entwicklung und keiner ist allgemein akzeptiert320.
Die wichtigsten Konzepte zur Integration auf dieser Ebene sind Electronic Data
Interchange (EDI) und XML-basierter Datenaustausch321. Obwohl die Verbreitung
315
316
317
318
319
Vgl. Manz et al. (2004, S. 1)
320
Vgl. Hu und Grefen (2002, S. 557); Glos (2007); Chong und Ooi (2008, S. 531)
321
Siehe zur historischen Entwicklung auch die Tabelle 1 in Kapitel 3.1: EDI bzw. EDIFACT Integration gilt als erste technologische Phase der betrieblichen Integration, danach folgte die XML-basierte
Integration (Phase 2).
77
von klassischem EDI langsam verlief322, ist es wohl die in der Praxis am häufigsten
anzutreffende Form des zwischenbetrieblichen Datenaustausches323. EDI bezeichnet
ein Konzept für den direkten, elektronischen Austausch standardisierter Geschäftsdokumente und Informationen in einem maschinenlesbaren Format, wodurch eine
automatisierte Weiterverarbeitung ermöglicht wird324. Studien zur Verbreitung und
Nutzung von EDI basieren zumeist auf Roger’s Diffusion of Innovation Theorie oder
Tornatzky und Fleischer’s TOE Framework325. Für die Nutzung spricht neben einer
Beschleunigung der Geschäftsabwicklung vor allem die drastische Reduzierung von
papierbasierten Dokumenten und den damit einhergehenden Qualitätssteigerung
durch das Wegfallen einer manuellen Bearbeitung und fehlerhaften Datenerfassung326. Da der Dokumentenaustausch bei EDI über proprietäre, aber private Netzwerke verläuft, besteht ein geringeres Sicherheitsrisiko als bei Übertragungen über
öffentliche Netzwerke wie das Internet327. Negativ auf der anderen Seite ist jedoch,
dass Aufbau und Nutzung eines privaten Netzes kostenintensiv ist und spezielles,
technisches Know-How erfordert. Deshalb wurde EDI vor allem von Großunternehmen eingesetzt328. Das Internet und Web-Technologien haben die Datenintegration
allerdings auch für KMUs erschwinglich und damit interessant gemacht329. Die Möglichkeiten reichen nun von WebEDI, also der Verwendung einer kostengünstigen
Web-Schnittstelle zum EDI Datenaustausch, bis zur Nutzung von diversen XMLbasierten Formaten und Standards330. Um das Problem der Heterogenität der vielen
unterschiedlichen Standards zu verringern, wird für die Integration auf der Datenebene die Anreicherung der Daten mit semantischen Informationen vorgeschlagen331.
Durch Ontologien können beispielsweise Produktdaten leichter in den verschiedenen
Standards abgeglichen und automatisiert ausgetauscht werden332. Jede Art der
Standardisierung hilft zwar Probleme bei der Integration zu vereinfachen, eine voll-
322
Vgl. Segev et al. (1997, S. 2)
323
Vgl. Elgarah et al. (2005, S. 8)
324
Vgl. Crum et al. (1996, S. 44); Elgarah et al. (2005, S. 8); Zimmermann (2007, S. 128)
325
Vgl. Chong und Ooi (2008, S. 533–534) ; siehe auch Kapitel 3.2.2.3 (DoI Theorie) bzw. Kapitel
3.2.2.4 (TOE Framework).
326
Vgl. Zimmermann (2007, S. 127); Bergeron und Raymond (1992, S. 19); Yang und Papazoglou
(2000, S. 40)
327
328
Vgl. Dan et al. (2001, S. 69); Omelayenko (2002, S. 1)
329
Vgl. Chou et al. (2004, S. 338)
330
Vgl. Medjahed et al. (2003, S. 64); Jeong et al. (2008, S. 1651)
331
Vgl. Bussler et al. (2002, S. 24)
332
Vgl. Omelayenko (2001), (2002); Joung und Chuang (2009, S. 53)
78
ständig funktionierende Lösung erfordert allerdings fast zwangsläufig ein gewisses
Maß an Anpassung333.
Das Ziel dieser Arbeit ist nicht, einzelne Standards zur betrieblichen Integration im
Detail zu beschreiben. Für eine Darstellung von Standards in Form einer „Standardisierungs-Road-Map“ sei an dieser Stelle auf die Arbeit von Manz et al.334 verwiesen.
Auch Medjahed et al.335 geben einen Überblick über Standards auf den Ebenen der
Kommunikation, auf inhaltlicher Ebene und auf Ebene der Prozesse. Nurmilaakso et
al.336 analysieren prominente XML-basierte Rahmenwerke und Standards für EBusiness. Otto et al.337 liefern neben einer Klassifikation gängiger Formate zusätzlich
eine Umfrage zur Verbreitung und Akzeptanz. Einen fundierten Überblick über EBusiness Standards und deren Haupteinsatzgebiete liefern auch Lebender et al.338.
Die Autoren identifizieren dabei zwei unterschiedliche Arten, die in der Folge noch
weiter verfeinert werden (Abbildung 18):

Anwendungsorientierte Standards stehen im Zusammenhang mit speziellen
Anwendungsbereichen und werden auf inhaltlicher Ebene zur Produktdatenklassifikation, zur Durchführung von Geschäftstransaktionen (dh. zum Austausch von Katalogdaten oder Geschäftsdokumenten) oder als Rahmenwerke
eingesetzt.

Technologieorientierte Standards werden für die tatsächliche Implementierung von E-Business Anwendungen eingesetzt. Technologieorientierte Standards werden beispielsweise für Web Services benötigt.
333
Vgl. Piccinelli et al. (2003, S. 1063)
334
Vgl. Manz et al. (2004)
335
Vgl. Medjahed et al. (2003)
336
Vgl. Nurmilaakso et al. (2006)
337
Vgl. Otto et al. (2002)
338
Vgl. Lebender et al. (2003, S. 25–38)
79
Abbildung 18: Einsatzbereiche von E-Business Standards339
Web Services sind vor allem in der Industrie sehr beliebt. Als Abstraktionsschicht
zwischen proprietärer Hardware und Software Plattformen haben sie sich als flexible
Schnittstelle erwiesen340. So finden Web Services sowohl für die innerbetriebliche
Integration als auch zwischen Unternehmen und zu Endkunden Einsatz341. Das W3C
definiert Web Services wie folgt:
“A Web Service is a software application identified by a URI [IETF RFC 2396], whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based
messages via Internet-based protocols.”342
Durch die Nutzung von XML als Datenformat erhöht sich tendenziell die Unabhängigkeit von Herstellern und die Integration lässt sich effizienter gestalten. Das hilft
letztendlich, die Kosten betrieblicher Integration zu senken343. Zusätzlich bringen
Web Services gegenüber klassischem EDI Vorteile in der einfachen Datenübertragung und Erweiterbarkeit mit sich344.
Die Integration auf der Datenebene schafft meist die technischen Voraussetzungen
für eine betriebliche Integration auf weiteren Ebenen. Diese konzeptuelle Ebene wird
339
340
Vgl. Vrieze et al. (2009, S. 64)
341
Vgl. Huang und Chung (2003, S. 16); Vlachakis et al. (2003, S. 15)
342
W3C Working Draft 28 October 2002
343
Vgl. Quantz und Wichmann (2003, S. 11)
344
Vgl. Hwang und Kenyon (2004, S. 556)
80
daher auch in allen betrachteten Ansätzen berücksichtigt345. So gilt beispielsweise
eine Datenintegration mittels Web Services als Voraussetzung für eine serviceorientierte Architektur und einer Integration auf der Ebene der Prozesse und Services346.
3.4.2 Integration auf Ebene der betrieblichen Informationssysteme
In den meisten Fällen ist eine Integration auf Datenebene nicht ausreichend. Vielfach
ist es notwendig, betriebliche Informationssysteme durch Standard- oder proprietäre
Schnittstellen zu verbinden, wobei der Trend hin zu Standardschnittstellen geht347.
Informationssysteme haben daher immer schon eine wichtige Rolle in der betrieblichen Integration eingenommen348. Betriebliche Informationssysteme gelten als eine
notwendige aber nicht als ausreichende Bedingung für unternehmerischen Erfolg. Es
benötigt auch Entscheidungsträger und handelnde Personen, welche die komplexen
Verflechtungen der angebotenen Informationen im betrieblichen Kontext beurteilen
können349.
Es gibt viele unterschiedlichen Arten von betrieblichen Informationssystemen. Einen
gut strukturierten Überblick liefern Schubert und Wölfle350, die eine Einteilung in die
vier Bereiche Basisanwendungen, „Business Software“, Groupware und fachspezifische Anwendungen vornehmen (siehe Abbildung 19).
345
Siehe Abbildung 17, Vergleich in Kapitel 3.4
346
Vgl. Kunti et al. (2007)
347
348
Vgl. Zhang et al. (2007, S. 267); Shore (2006, S. 102)
349
Vgl. Beynon-Davies (2009, S. 97)
350
Vgl. Schubert und Wölfle (2007, S. 20–21)
81
Abbildung 19: Übersicht über betriebliche Informationssysteme im Unternehmen351
Zu den Basisanwendungen zählen die Autoren die gängigen Büroanwendungen zur
Textverarbeitung, Tabellenkalkulation etc., Systeme zur Authentifikation und Nutzung
gemeinsamer Netzwerk-Laufwerke, Content Management Systeme (CMS) und
Systeme zur sicheren Anbindung nach außen wie Firewalls.
Der Bereich der „Business Software“ unterstützt strukturierte Geschäftsprozesse
und verwaltet die Daten, die bei geschäftlichen Transaktionen anfallen352. Wichtige
unternehmensweite Systeme aus diesem Bereich sind Enterprise Resource Planning
(ERP), Customer Relationship Management (CRM) und Supply Chain Management
(SCM) Systeme353. Ein ERP System versucht alle Firmeninformationen in einer
zentralen Datenbasis abzulegen. Dadurch wird es möglich, benötigte Informationen
von unterschiedlichen Stellen in der Organisation abzurufen und zu visualisieren 354.
Informationen werden transparent und wartbar355. In der Vergangenheit lag der
351
Vgl. Schubert und Wölfle (2007, S. 20)
352
353
Vgl. Chou et al. (2004, S. 338)
354
355
Vgl. Zaitun und Zaini (2008, S. 698)
82
Fokus von ERP Systemen auf der internen Integration von traditionellen Abteilungsfunktionen wie Produktion oder Warenwirtschaft. Mittlerweile verschwimmen die
Grenzen zu anderen Systemen (wie z.B. SCM Systemen) zusehends, da ERP System auch Funktionalitäten anbieten, um externe Partner entlang der Wertschöpfung
anzubinden356. Über Unternehmensgrenzen hinweg eingesetzte Systeme werden
auch als Interorganisationale Informationssysteme (IOS) bezeichnet357.
Groupware-Anwendungen stellen Personen in Arbeitsgruppen Informationen und
Kommunikationsmöglichkeiten zur Verfügung. Workflow Management Systeme
(WfMS) integrieren meist „Business Software“ Applikationen bei der Abbildung von
einmaligen oder wiederkehrenden Geschäftsprozessen. Bei den Kollaborationssystemen unterschieden die Autoren zwischen synchronen und asynchronen. Synchrone Kollaborationssysteme unterstützen die gleichzeitige Arbeit mehrerer Personen an
verschiedenen Standorten (z.B. Instant Messaging, Voice over IP, Telefonkonferenzen, Videokonferenzen, Desktop-Sharing, Gruppen-Editoren). Im Gegensatz dazu
unterstützen asynchrone Kollaborationssysteme die zeitversetzte Zusammenarbeit
mehrerer Personen. Dazu zählen die Autoren E-Mail, virtuelle Laufwerke oder Projekträume, Newsgroups und Projektmanagementlösungen, aber auch Anwendungen
aus dem Web 2.0 wie Wikis, Blogs und RSS-Feeds358. Auch in diesem Bereich soll
keine scharfe Grenze zwischen Anwendungsklassen gezogen werden. Systeme
überlappen sich in ihren Funktionalitäten; so bieten CMS meist auch Möglichkeiten
zur synchronen sowie asynchronen Kollaboration und Basisfunktionalität zum Geschäftsprozessmanagement.
Betriebliche Informationssysteme gelten unter anderem als die Verwalter von Daten.
Die Ebene der betrieblichen Informationssysteme ist daher ebenso essentiell für
betriebliche Integrationslösungen, wie die zuvor besprochene Datenintegration und
wird auch in allen betrachteten Ansätzen berücksichtigt359.
3.4.3 Einsatz von dedizierter Software als „Middleware“ zur Integration
Der generische Begriff „Middleware“ hat sich in den 1980er Jahren auf dem Gebiet
des Enterprise Application Integration (EAI) etabliert. Middleware ist serverseitige
Software, die als Zwischenschicht zwischen verschiedenen, heterogenen Systemen
fungiert und die Kommunikation dieser Systeme ermöglicht360. Ziel ist es, anwen-
356
Vgl. Kelle und Akbulut (2005, S. 41); Eckartz et al. (2009, S. 1600); Kumar und van Hillegersberg
(2000, S. 26)
357
Vgl. Hu et al. (2010, S. 1); Liu et al. (2011, S. 153)
358
359
Siehe Abbildung 17, Vergleich in Kapitel 3.4
360
Vgl. Krallmann (2012, S. 110); Lebender et al. (2003, S. 14)
83
dungsübergreifend durchgängige Geschäftsanwendungen zu ermöglichen361, sodass
sich Entwickler auf die Abbildung der Geschäftsprozesse konzentrieren können362.
Dabei können drei Techniken unterschieden werden363:

Access Integration Middleware: Techniken zur Herstellung eines transparenten Zugriffs aus Anwendungen auf Hostsysteme oder Datenbanken.

Message-Oriented Middleware: Techniken zur Herstellung eines transparenten Nachrichtenaustausches zwischen mehreren Anwendungen.

Transaction Server Middleware: Techniken zur Herstellung einer transparenten und anwendungsunabhängigen Koordinierung von Nutzer- und Datenbanktransaktionen.
Aus konzeptueller Sicht erfüllt Middleware damit die Aufgabe eines Mittlers, wodurch
sie sich auch klar von der Integration auf Ebene der betrieblichen Informationssysteme abgrenzt. Da Middleware am Frontend meist allerdings nicht sichtbar und daher
durch den Nutzer nicht wahrgenommen wird, wird diese Ebene der Integration oft
ignoriert oder vergessen364. Software auf dieser Schicht greift zur Herstellung eines
transparenten Austausches auf die Datenebene zurück und stellt damit eine wichtige
Komponente für den Aufbau einer skalierbaren, fehlertoleranten, sicheren, auf Standards basierende IT-Architektur dar365. Sie wird zunehmend erforderlich, um dynamische und flexible Integration zwischen den Partnern in der Wertschöpfungskette
herzustellen366. Werden beispielsweise das Inhouse SCM System mit Daten vom
ERP System zusammengefügt und diese mit weiteren ERP Systemen von Partnerunternehmen gekoppelt, dann tritt Middleware als Zwischenschicht zur Transaktion
und Konvertierung der verschiedenen Datenformate des SCM Systems und der
unterschiedlichen ERP Systeme auf367. Microsoft Biztalk ist ein Beispiel einer kommerziell verfügbaren Middleware, die Geschäftsprozesse mit Schwerpunkt auf Unterstützung von E-Commerce auf XML-Basis integriert368.
361
Vgl. Wölfle (2007, S. 15)
362
363
Vgl. Nehring (2003, S. 7)
364
Vgl. Vinoski (2002, S. 92)
365
Vgl. Vojdani (2003, S. 555)
366
Vgl. Dan et al. (2001, S. 68)
367
Vgl. Ball et al. (2002, S. 62)
368
Vgl. Herring und Milosevic (2001, S. 3)
84
3.4.4 Integration auf der sozialen Ebene
Die soziale (oder kollaborativ-soziale) Ebene hat vor allem in den letzten Jahren an
Bedeutung gewonnen. Nachdem O'Reilly den Begriff „Web 2.0“ im Jahr 2003 bei der
Vorbereitung auf eine wissenschaftliche Konferenz prägte369 und McAfee mit „Enterprise 2.0“ im Jahr 2006 folgte370, gewann auch die Anbieterlandschaft für Unternehmenslösungen an Form und Dynamik. Die aktuell diskutierten Konzepte des Enterprise 2.0 subsumieren die Nutzung interaktiver und kollaborativer Web 2.0 Konzepte
und Technologien für den Einsatz in und zwischen Unternehmen371:
„Enterprise 2.0 is the use of emergent social software platforms within companies, or between companies and their partners or customers.“372
Enterprise 2.0 Werkzeuge und Plattformen verschmelzen mit betrieblichen Informationssystemen und sind somit bei einer State-of-the-art Betrachtung von Integrationslösungen nicht außer Acht zu lassen. Im Allgemeinen stellt Enterprise 2.0 verbesserte Möglichkeiten zum inner-, über- und zwischenbetrieblichen Informations- und
Wissensaustausch sowie zur Kommunikation und Kollaboration zur Verfügung373.
Diese Konzepte und Technologien erweitern die personale Ebene um eine soziale
Ebene mit kostengünstigen und einfach zu verwendenden Werkzeugen374. Allerdings
müssen Konzepte einheitlich betrachtet und technisch über eine einzige Schnittstelle
angebunden werden, um ihr volles Potenzial zu erreichen375. In Übereinstimmung mit
Koch und Richter wird Enterprise 2.0 weder als ein neuer Forschungsbereich noch
als eine komplette Revolution in den Unternehmen gesehen376. Ferner stellt es eine
evolutionäre Weiterentwicklung des Internets zu einem alltagstauglichen Massenmedium dar377.
Die Grundlage für eine Integration auf sozialer Ebene bilden die Konzepte der partizipativen Gestaltung, dezentralen Organisation („Bottom-Up“) und evolutionären
Entwicklung378, die im Zusammenspiel mit verfügbaren Technologien und Werkzeugen zu dem führen, was gemeinhin unter Enterprise 2.0 verstanden wird. Neu sind
369
Vgl. O'Reilly (2007, S. 17)
370
Vgl. McAfee (2006a, S. 1), (2006b, S. 23–25)
371
Vgl. McAfee (2009); Back et al. (2012)
372
McAfee (2006a, S. 1)
373
Vgl. Büchner et al. (2009, S. 1); Riedl und Betz (2012, S. 1)
374
Vgl. Bächle (2008, S. 131)
375
Vgl. Polaschek et al. (2012, S. 2)
376
Vgl. Koch und Richter (2007, S. 16)
377
Vgl. Bächle (2008, S. 131)
378
Vgl. Koch und Richter (2009, S. 167); Chui et al. (2009)
85
dabei nicht immer die einzelnen Bestandteile, sondern vor allem das Zusammenspiel
dieser Elemente379. Abbildung 20 zeigt die angesprochenen Konzepte und ausgewählte Technologien und deren Anwendungen bzw. Werkzeuge im Unternehmensumfeld.
Abbildung 20: Grundlegende Konzepte für Enterprise 2.0 und Beispiele von Technologien und
Werkzeugen380
Der Begründer des Begriffs Enterprise 2.0 verwendet das Akronym „SLATES“ (Search, Links, Authoring, Tags, Extensions, Signals) zur Benennung jener sechs Charakteristika, die für die Umsetzung von Enterprise 2.0 im Unternehmen entscheidend
sind381:
• Search: Auffinden der exakt gesuchten Information mittels unternehmensweiter Suche („Enterprise Search“; z.B. Indizierung von Informationen aus Dateisystem, betrieblichen Informationssystemen und externen Informationen).
• Links: Verlinkung der wichtigsten Informationen an prominenter Stelle (z.B.
mittels „Social Bookmarking“).
• Authoring: Kommunikation und Kollaboration ermöglicht durch einfaches Erfassen, Editieren und Kommentieren von Informationen von den eigenen Mitarbeitern (z.B. in Projektgruppen, abteilungsübergreifend, unternehmensweit
oder unternehmensübergreifend mittels Wikis, Blogs, webbasierten Gruppeneditoren und Instant Messaging).
379
Vgl. Dufft und Tietz (2007, S. 4)
380
In Anlehnung an Dufft und Tietz (2007, S. 4)
381
Vgl. McAfee (2006b)
86
• Tags: Informationen, die über Link- und Authoring-Technologien zur Verfügung gestellt wurden, können durch die Vergabe von Schlüsselwörtern kategorisiert und somit leichter aufgefunden werden (z.B. mittels „Social Tagging“).
• Extensions: Analysieren der Aktivitäten der authentifizierten Nutzer und Anpassung der Angebote nach deren Vorlieben über ein (semantisches) Empfehlungssystem.

Signals: Benachrichtigen der Nutzer bei neuen, relevanten Informationen
über das Abonnieren von Newsfeeds (z.B. RSS-/ATOM-Feed).
Abbildung 21 zeigt das breite Spektrum einzelner Anwendungen und Werkzeuge
durch deren Anordnung nach den SLATES-Charakteristika. Je näher das Werkzeug
dabei einer der SLATES-Charakteristika kommt, desto eher priorisiert es das Charakteristikum und auch umso spezialisierter ist dessen Funktionalität. So dienen beispielsweise Newsfeeds ausschließlich der automatischen Benachrichtigung („Signals“). Blogs und auch Wikis hingegen unterstützen mehrere SLATESCharakteristika, allen voran „Authoring“ und „Links“.
Abbildung 21: Zuordnung von Enterprise 2.0 Werkzeugen zu den SLATES-Charakteristika (eigene
Darstellung)
Insbesondere für größere Unternehmensstrukturen können soziale Netzwerke sehr
wertvoll sein. Durch die Angabe von Profilinformationen, Interessen und Kompetenzen, früheren Arbeitgebern, Projekten, Kollegen, usw. lassen sich etwa Lücken in
87
Kompetenzfeldern identifizieren, relevante Informationen für Nutzer filtern und leichter auffinden oder bestehende Lösungen zu eigenen Problemen finden382. Für soziale Netzwerke sind daher ebenso mehrere Charakteristika wie einfache Möglichkeiten
zum Verlinken, Erfassen, Editieren und Kommentieren sowie Tagging und Rating von
Inhalten notwendig.
Ein Mashup383 ist keine Anwendung im engeren Sinne, da Mashups erst entstehen,
wenn Inhalte, Daten oder Funktionalitäten aus verschiedenen Quellen miteinander zu
individuellen Anwendungen kombiniert werden384. Sie bieten erweiterte Möglichkeiten für flexible Anwendungen mit Einbindung beliebiger interner und externer Inhalte385. Je nach Kombination können durch Mashups unterschiedliche Charakteristika
angesprochen werden, weshalb sie in der Mitte der Abbildung dargestellt sind.
Zusammenfassend lässt sich feststellen, dass die Konzepte auf der sozialen Ebene
zu einer besseren Zusammenarbeit im Unternehmen führen können, sofern ihnen die
nötige Beachtung zukommt. Es ist primär keine Frage der Einführung neuer Technologien, sondern neuer Arbeitsabläufe und Methoden. In einem ersten Schritt vor der
Einführung sollten Manager daher die zugrundeliegenden Fähigkeiten ihrer Organisation umfassend untersuchen386. Die soziale Ebene ist damit keinesfalls isoliert zur
betrachten. Zur Identifikation von Schwachstellen und Vermeidung von Doppelarbeiten ist beispielsweise eine Untersuchung von Prozessen erforderlich und bestehende
betriebliche Informationssysteme zur Groupware und Business Software sind bestmöglich zu integrieren. Anbieter haben zwar verstärkt Anstrengungen zur Verbindung
von prozessorientierter und kommunikationsorientierter Arbeitsweisen unternommen,
die Lücke in den Anwendungen sowie die Verbindung auf technischer und organisatorischer Ebene wurde jedoch noch nicht geschlossen387.
3.4.5 Integration auf Ebene der Prozesse und Services
Einer der wichtigsten Voraussetzungen für betriebliche Integration ist die Kompatibilität auf der Geschäftsebene. Dies erfordert in vielen Fällen eine Formalisierung der
Geschäftsprozesse in einer einheitlichen und erweiterbaren Weise, um eine elektronische Kommunikation auf Ebene der Prozesse zu ermöglichen388. Prozessorganisa-
382
Vgl. Ferron et al. (2011, S. 77–78)
383
Mashups werden im Unternehmenskontext auch als „Enterprise Mashups“ bezeichnet.
384
Vgl. Hoyer und Stanoevska-Slabeva (2008, S. 60); Vrieze et al. (2011, S. 637)
385
Vgl. Vrieze et al. (2009, S. 64)
386
Vgl. Hain und Back (2011, S. 1)
387
Vgl. Wölfle (2007, S. 2)
388
Vgl. Yang und Papazoglou (2000, S. 42)
88
tion ist zu einer Grundlage des Erfolgs eines Unternehmens geworden, daher wird
der Automatisierung von Prozessen und der Schaffung offener Geschäftsprozesse
zur Integration von Geschäftspartnern zunehmend Aufmerksamkeit zuteil389. Mit der
Einführung von neuen technologischen Möglichkeiten durch das World Wide Web,
wird das Internet als Plattform für die Umsetzung von komplexen Geschäftsanwendungen verwendet. Selbst einfache E-Business Anwendungen beinhalteten heute
eingebettete Geschäftsprozesse, die korrekt ausgeführt werden müssen, um den
Erfolg der verteilten Anwendung zu gewährleisten390. Um die strukturelle Heterogenität auf Ebene der Geschäftsprozesse in den Griff zu bekommen, betonen verschiedene Quellen wiederum die Notwendigkeit der Verwendung von Standards zur
Prozessintegration391.
Trends wie die Globalisierung und die breite Verfügbarkeit von Technologien zur
Integration führen zu einer vermehrten Nutzung von Outsourcing392. Outsourcing ist
nach DIN definiert als „Auslagerung von Leistungen oder Funktionen eines Unternehmens an externe Dienstleister“393. Die Beweggründe für Outsourcing liegen
Umfragen zufolge in der Kostenreduktion, im Fokus auf Kernkompetenzen, im Zugang zu externer Expertise, in einer Effizienzsteigerung und in technischen Gegebenheiten394. Gegenstand des Outsourcings sind entweder Geschäftsprozesse395
oder der Betrieb von IT396 bzw. eine Kombination dieser beiden. Neben klassischem
IT-Outsourcing eröffnet vor allem das Outsourcen ganzer Geschäftsprozesse die
Möglichkeit Synergien optimal zu nutzen. Betrachtet man den Betrieb der ausgelagerten Informationstechnologie als technisch geprägte Geschäftsprozesse, so stellt
auch IT-Outsourcing ein Auslagern von Prozessen dar397. Outsourcing von Geschäftsprozessen als Maßnahme der internen Leistungssteigerung spielt auf dieser
Ebene daher eine zentrale Rolle. Dies mag auf den ersten Blick paradox erscheinen:
Auf der einen Seite herrscht Druck, Arbeitsabläufe zu dezentralisieren und entsprechende Geschäftsprozesse auszulagern. Auf der anderen Seite gibt der herrschende
Wettbewerbsdruck vor, die über das Unternehmen verteilt agierende Verwaltung zu
389
390
Vgl. Rossi et al. (2003, S. 359)
391
Vgl. Medjahed et al. (2003, S. 62); Jung et al. (2006); Lebender et al. (2003, S. 19)
392
Vgl. Ardagna et al. (2011, S. 61); Poon und Lau (2006, S. 96)
393
DIN SPEC 1041:2010-05, S. 7
394
Vgl. Lacity et al. (2009, S. 134); Kumaran et al. (2007, S. 513); Norta et al. (2006, S. 834)
395
Englisch: „Business Process Outsourcing“, abgekürzt als „BPO“; Vgl. Whitaker et al. (2010, S. 1)
396
Englisch: „Information Technology Outsourcing“; abgekürzt als „ITO“; Vgl. Loh und Venkatraman
(1992); Willcocks et al. (1995, S. 334)
397
Vgl. DIN SPEC 1041:2010-05, S. 14
89
zentralisieren und zu integrieren398. Diese beiden Seiten stehen jedoch nicht im
Widerspruch zueinander. Es ist ratsam, beide Seiten zu vereinen, um ein optimales
Ergebnis zu erzielen. So sind sowohl interne Strukturen effizienter zu gestalten, als
auch eine Integration von Geschäftsprozessen mit externen Partnern vorzunehmen.
Die Voraussetzung für eine vollverantwortliche Übertragung betrieblicher Prozesse
ist deren Überführung in definierte Services399. Im Gegensatz zu einem Prozess sind
bei einem Service mehr die externen Beziehungen und die Qualitäten dieser Resultate von Bedeutung als die interne Sicht der Aktivitäten und Abläufe400. Die Definition
von Services adressiert die Notwendigkeit einer flexiblen und möglichst raschen
Reaktion auf Prozessveränderungen, der sich Unternehmen konfrontiert sehen.
Diese Änderungen in den Geschäftsprozessen stellen neuen Anforderungen an die
unterstützenden betrieblichen Informationssysteme und die jeweils zugrunde liegende Architektur401. Das Konzept der serviceorientierten Architektur (SOA) adressiert diese Wiederverwendbarkeit der implementierten Dienstleistungen bei der
Anpassung und Optimierung der realisierten Prozesse für neue Anwendungskontexte402.
Zum Geschäftsprozess-Outsourcing, welches durch eine SOA gefördert wird, haben
sich neue Lizenz- und Servicemodelle gebildet. Unternehmen versuchen sich mehr
und mehr von traditionellen „On-Premise“403 Anwendungen weg zu bewegen404. Als
Folge daraus sind verschiedene „On-Demand“ Outsourcing-Modelle entstanden,
wobei Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) und Infrastructure-as-a-Service (IaaS) am häufigsten genutzt werden. Während bei IaaS
Hardware-Ressourcen bei Bedarf bereitgestellt werden, sind es bei SaaS Standardsoftwarelösungen, die der Anwender als Dienstleistung über das Internet nutzen
kann. Die SaaS-Anwender zahlen monatliche, quartalsbasierte oder jährliche Nutzungsgebühren für die gemieteten Services und der SaaS-Anbieter ist für Betrieb
und Wartung der mehrmandantenfähigen Software verantwortlich. Alle anfallenden
Kosten sind im Voraus bekannt und vertraglich vereinbart. Das PaaS-Konzept nimmt
die Rolle einer Middleware ein, indem die notwendige Betriebsplattform für die virtuell
398
Vgl. Shore (2006, S. 102)
399
Vgl. DIN SPEC 1041:2010-05, S. 7
400
Vgl. DIN SPEC 1041:2010-05, S. 9; Norta et al. (2006, S. 834)
401
Vgl. Thomas et al. (2007, S. 5)
402
Vgl. Quantz und Wichmann (2003, S. 11); Wölfle (2007, S. 15); Contreras und Sheremetov (2008,
S. 680)
403
„On-Premise“ bedeutet, dass Anwendungen im eigenen Rechenzentrum gehostet und betrieben
werden.
404
Vgl. Anstett et al. (2009, S. 670)
90
angebotene Software transparent darstellt wird405. Das Servicemodell funktioniert
aber nicht mit allen Unternehmensanwendungen gleich gut. Spezifische Anwendungen wie CRM oder Office-Anwendungen wie E-Mail, bei denen die Funktionalität gut
strukturiert und allgemein akzeptiert ist, haben SaaS-Anwendungen größere Chancen von den Nutzern akzeptiert zu werden406. Auch die elektronische Rechnungslegung wird oft als Service mit Zusatzleistungen über SaaS angeboten407.
Geschäftsprozess-Outsourcing ist ein stetig wachsender Trend. Mit zunehmender
Standardisierung von Geschäftsprozessen wird erwartet, dass er Organisationen in
der Zukunft noch weiter durchdringen wird408. So wie das Internet die humanzentrierten Seite auf sozialer Ebene durch Enterprise 2.0 Konzepte verändert, so
erlebt auch die technisch-strukturelle Seite einen Wandel von anwendungsorientierter zu serviceorientierter Architektur; sowohl innerhalb des Unternehmens als auch
zwischenbetrieblich409.
3.5 Zusammenfassung
Im gegenständlichen Kapitel wurde die wissenschaftliche Fragestellung (FS1) beantwortet. Dafür war es im ersten Schritt nötig, sich mit unterschiedlichen Definitionen des Begriffs der betrieblichen Integration auseinanderzusetzen. Im zweiten
Schritt wurden die Integrationsdimensionen hergeleitet, die es für eine holistische
Betrachtung betrieblicher Integration zu beachten gilt. Der dritte Schritt galt der
Beschreibung relevanter Ansätze und Rahmenwerke der betrieblichen Integration
und Identifikation der enthaltenen Ebenen. Im abschließenden vierten Schritt wurden
die in den Ansätzen und Rahmenwerken einer vergleichenden Analyse unterzogen
und die relevanten Integrationsebenen identifiziert.
Die Basis für das gegenständliche Kapitel wurde durch einen Vergleich von Definitionen betrieblicher Integration in Kapitel 3.1 gelegt. Auch wenn der Begriff teilweise
synonym verwendet wird, sind einige Unterschiede in den Definitionen auszumachen. Die Hauptunterschiede ergeben sich aufgrund der verwendeten Sichtweise
(intern oder extern) oder des betrachteten Kontextes (E-Business, E-Commerce,
405
Vgl. Beimborn et al. (2011, S. 371); Chou und Chou (2008, S. 386); Yao et al. (2011, S. 299);
Buxmann et al. (2008, S. 500); Yao et al. (2011, S. 299); Sun et al. (2008, S. 18); Ma (2007, S. 701);
Waters (2005, S. 36)
406
Vgl. Pathirage et al. (2011, S. 121); Benlian et al. (2009, S. 424–425)
407
Vgl. Keifer (2011, S. 38); Siehe auch Fallstudie 2 zur elektronischen Rechnungslegung in
Kapitel 6.3
408
Vgl. Lacity et al. (2009, S. 141)
409
Vgl. Carey (2008, S. 92)
91
Web Services, etc.). Zusätzlich konnte gezeigt werden, dass die Definitionen unterschiedliche Aspekte bzw. Ebenen bei der betrieblichen Integration hervorheben
(Mensch, Organisation, Geschäftsprozess, Service, etc.). Bei der betrieblichen Integration sind daher neben den technischen Aspekten auch immer die humanzentrierten Aspekte kommunikativer, koordinativer, kooperativer und kollaborativer
Zusammenarbeit anzusprechen. Das Ziel ist die Herstellung eines optimalen Grades
an Integration zur Zusammenarbeit.
Daran anschließend wurde der Forschungskontext durch eine Betrachtung von
Integrationsdimensionen anhand gängiger Erklärungsansätze zur Integration detailliert und konkretisiert (Kapitel 3.2). Das Wissen über den Partnerschaftsprozess und
mögliche Motive und Gründe für das Auslösen einer betrieblichen Integration wird für
die gegenständliche Arbeit als wichtig erachtet. Es ist dann eine betriebliche Integration im Sinne der Arbeit, wenn es zu einem Prozess zum Aufbau von Partnerschaftsbeziehungen kommt. Eine lose Geschäftsbeziehung (z.B. Einkauf über ein Portal) ist
nicht im Fokus der Arbeit. Es konnte gezeigt werden, dass der Prozess der Einführung von komplexen Integrationslösungen von Faktoren im Kontext der Technologie, der Organisation (inner-, über- und zwischenbetrieblich) und des betrieblichen
Umfeldes (Rahmenbedingungen) beeinflusst wird. Eine Analyse mit Bedacht auf
diese Gesichtspunkte ist notwendig, um Barrieren und Widerstände in Integrationsprojekten zu erkennen und in der Folge abwenden zu können. Diese drei Kontexte
(Technologie, Organisation, Umfeld) werden in der gegenständlichen Arbeit als
Integrationsdimensionen bezeichnet.
In Kapitel 3.3 wurden neun ausgewählte Rahmenwerke und konzeptuelle Architekturmodelle zur betrieblichen Integration im Detail diskutiert. Damit wurde ein Überblick über anerkannte und relevante Ansätze aus der Literatur gegeben und die in
diesen Ansätzen behandelten Ebenen beschrieben.
Daran anschließend wurden diese in Kapitel 3.4 einer vergleichenden Analyse unterzogen und damit ein Bezugsrahmen für die gegenständliche Arbeit hergestellt.
Im Quervergleich der Ansätze zeigten sich fünf dominante konzeptuelle Ebenen, die
von einer betrieblichen Integration betroffen sein können. Auf den Ebenen kommen
unterschiedliche Konzepte zur Integration zum Einsatz, die eingehend besprochen
wurden. Diese Ebenen werden in der gegenständlichen Arbeit als Integrationsebenen bezeichnet:

Integration auf Ebene der Daten (EDI- und XML-basierter Datenaustausch
und Einsatz von Datenbanken zur persistenten Speicherung, Standards zum
Datenaustausch z.B. via Web Services)
92

Integration auf Ebene der betrieblichen Informationssysteme (Austausch
von Dokumenten und Informationen aus ERP Systemen wie z.B. SAP iDoc)

Einsatz von dedizierter Software als „Middleware“ zur Integration (Datenaustausch-Server als Zwischenschicht zur transparenten Integration von Daten
aus Informationssystemen, z.B. Microsoft BizTalk)

Integration auf der sozialen Ebene (Einsatz von „Enterprise 2.0“ Konzepten
und Technologien wie z.B. Blogs zur Top-Down Kommunikation und RSSFeeds zur automatischen Benachrichtigung)

Integration auf Ebene der Prozesse und Services (Outsourcing von Geschäftsprozessen, Anbieten von Services und Diensten als SaaS, usw.)
Die Ebenen sind so angeordnet, dass die erstgenannten Schichten (wie Daten- und
Informationssystemebene) tendenziell eine stärkere operative Ausrichtung und die
letztgenannten Schichten (wie die Prozess- und Serviceebene) aus strategischer
Sicht mehr Relevanz haben. Auch überwiegt die technologische Dimension in der
Datenschicht, während die organisatorischen und inter-organisatorischen Zusammenhänge sowie Rahmenbedingungen aus dem Umfeld in der sozialen Ebene sowie
der Prozess- und Serviceebenen stärkeren Einfluss auf die betriebliche Integration
ausüben.
Diese intensive Betrachtung der Dimensionen und Ebenen einer Integration werden
als wesentlich erachtet. Das Wissen über Einflussfaktoren aus den Integrationsdimensionen und grundlegende Konzepte auf unterschiedlichen Integrationsebenen
bilden den Rahmen für eine Beschreibung betrieblicher Integrationslösungen. Vielen
Unternehmen fehlt jedoch ein umfassendes Verständnis betrieblicher Integration
sowie geeignete Strategien und Methoden zur Verknüpfung der Integrationsdimensionen und -ebenen410. Sabherwal und Robey beschreiben diesen Wissensstand
folgendermaßen:
“The state of knowledge is analogous to cooking with a list of ingredients but without the
recipe. We need more research on how the ingredients are combined before a recipe for
successful implementation can be prescribed.” 411
410
411
Sabherwal und Robey (1993, S. 549)
93
Neben einem Bezugsrahmen wird also ein Vorgehen benötigt, wie diese einzelnen
Komponenten zu einer ganzheitlichen Lösung zusammengesetzt werden können.
Ein Vorgehensmodell adressiert eben diesen Prozess der Durchführung. In einem
Vorgehensmodell zur Einführung von betrieblichen Integrationslösungen sollen daher
diese Komponenten in einen sinnvollen und praxistauglichen Ablauf gebracht werden.
94
Explorative Studie zur Bestimmung der Praxisrelevanz
4 Explorative Studie zur Bestimmung der
Praxisrelevanz
Das Kapitel enthält Ergebnisse aus einer quantitativen empirischen Erhebung in
österreichischen Unternehmen zur betrieblichen Integration. Mit der in einer frühen
Phase der Forschungsarbeit durchgeführten Voruntersuchung, sollten erste Einsichten zur aktuellen Situation betrieblicher Integration im Zielgebiet gewonnen werden412. Damit wird die wissenschaftliche Fragestellung (FS2) beantwortet: Wie wird
der Bedarf an betrieblicher Integration von österreichischen Unternehmen eingeschätzt? Als Ergebnis der Beantwortung lassen sich Meinungen aus der gängigen
Unternehmenspraxis empirisch belegen. Die daraus gewonnenen Erkenntnisse
können im Projekt aufbereitet und Unternehmen bei der Einschätzung ihres Integrationsbedarfs unterstützt werden.
Das Kapitel gliedert sich wie in Abbildung 22 ersichtlich in drei Abschnitte. Kapitel 4.1
beinhaltet die Methodik der Studie. Dabei werden die Ziele der Studie dargelegt, auf
den Themenkatalog, auf den Ablauf der Befragung sowie auf die Vorgehensweise
bei der Auswertung der Ergebnisse eingegangen. Wesentliche Ergebnisse aus der
Studie werden in Kapitel 4.2 diskutiert. Den Abschluss bildet eine kurze Zusammenfassung in Kapitel 4.3.
412
Siehe dazu auch Kapitel 2.2.2
95
4.1 Methodik der Studie
Ausgangspunkt der explorativen Studie bilden die in Kapitel 3 erläuterten Grundlagen. Ziel und Ansatz der Hypothesenbildung, der Ablauf und die Vorgehensweise bei
der Ergebnisauswertung werden nun vorgestellt.
4.1.1 Ziel der Befragung
Hauptziel der Untersuchung ist es, durch eine Bestandsaufnahme mehr über die
aktuelle Situation von betrieblicher Integration in österreichischen Unternehmen
unterschiedlicher Größenordnung herauszufinden und die Relevanz betrieblicher
Integration aufzuzeigen. Es sollten etwa konkrete aktuelle Problemebereiche identifiziert sowie die Ziele betrieblicher Integration erhoben werden. Ein zusätzliches Ziel
der Untersuchung war das Auffinden interessierter Unternehmen für Fallstudien oder
Pilotprojekte. Die Befragung wurde zwar anonym durchgeführt, es gab aber auch am
Ende der Befragung die Möglichkeit einer Kontaktaufnahme durch Hinterlassen der
Kontaktadresse des ausfüllenden Unternehmens.
In der Literatur wird oft ein Unterschied in der Nutzung von Informationstechnologie
allgemein bzw. E-Business und E-Commerce im Speziellen zwischen kleinen und
großen Unternehmen nachgewiesen. So werden KMUs im Jahr 2007 im Bericht einer
europaweiten Studie der Europäischen Kommission („e-Business W@tch“) als fehlendes Bindeglied in der Integration innerhalb eines Wertschöpfungsnetzwerks
bezeichnet, wodurch diese riskieren, durch integrationsfähigere Konkurrenten aus
dem Netzwerk ersetzt zu werden413. Diese digitale Kluft zwischen KMUs und Großunternehmen verhindert laut Bericht vom Jahr 2010 immer noch die optimale Nutzung von Netzwerkeffekten in Wertschöpfungsnetzwerken414. Die Studien zeigen
ebenfalls auf, dass vor allem KMUs den Einsatz und die Chancen von integrierten EBusiness Lösungen nicht in gleichem Ausmaß erkannt haben, bzw. die teilweise zu
teuren und komplexen Integrationsprojekte im Vergleich zu kapitalkräftigeren Großunternehmen nicht umsetzen können. Neben den nötigen finanziellen Mitteln fehlt es
KMUs auch häufig an der notwendigen strategischen Planung und technischem
Know-How415. Die dadurch entstehenden Wettbewerbsnachteile können nur durch
ganzheitliche und langfristige Miteinbeziehung der kleineren Unternehmen abgewendet werden.
413
Vgl. European Commission (2007, S. 9)
414
Vgl. European Commission (2010, S. 11)
415
Vgl. Ferneley und Bell (2006); Gulledge (2002, S. 56); Leimstoll und Schubert (2005, S. 984); Levy
und Powell (2000, S. 64)
96
KMUs sind demnach in ihrer Technologisierung und ihrem IT-Einsatz gegenüber
Großunternehmen benachteiligt, bilden aber einen wesentlichen Teil des wirtschaftlichen Rückgrats der österreichischen Wirtschaft. Zentraler Fokus der Auswertung
liegt daher auf relevanten Aussagen, Bewertungen und Einschätzungen von KMUs,
um die Evidenz einer Kluft in der betrieblichen Integration unter österreichischen
Unternehmen empirisch zu belegen. Um diesen latenten Nachteil, die Aktivitäten und
die Bedeutung betrieblicher Integration messen zu können, wurden basierend auf
den zentralen Themenbereichen des Fragebogens mehrere Hypothesen abgeleitet.
Der Fokus auf Unterschiede von Unternehmen unterschiedlicher Größe spiegelt sich
auch in den Hypothesen wider.
4.1.2 Themenkatalog
Basierend auf wissenschaftlicher Literatur und weiteren empirischen Untersuchungen
im Bereich der IT-Verwendung in Unternehmen, E-Business und E-Commerce wurden wichtige Faktoren, die den Status Quo betrieblicher Integration beschreiben,
ermittelt416. Der daraus resultierte Themenkatalog beinhaltet drei große Bereiche:

Basis und Voraussetzungen für betriebliche Integration („Readiness“):
Fokussiert wird auf Fragen inwieweit das Unternehmen die Voraussetzungen
für den Einsatz von betrieblicher Integration erfüllt. Dazu gehören neben Investitionen in die technische Infrastruktur und verfügbares Know-How im ITBereich auch schriftliche Strategien und Richtlinien in diesem Bereich.

Aktivitäten im Umfeld betrieblicher Integration („Activity“): Die Ermittlung
und Analyse des Einsatzes im Umfeld von betrieblicher Integration im Unternehmen ist Aufgabe dieses Bereiches. Es wird nach der Durchführung von
elektronischem Datenaustausch mit Kunden und Lieferanten gefragt sowie
nach der Durchdringung von betrieblichen Informationssystemen und der
Verwendung von Standards in diesem Bereich.

Bedeutung betrieblicher Integration („Impact“): Der dritte Bereich enthält
Fragen zu den Auswirkungen betrieblicher Integration auf den Unternehmenswert und Ziele oder mögliche Barrieren einer betrieblichen Integration.
4.1.3 Ablauf der Befragung
Für die Verwendung als Online Befragung wurde auf Basis des Themenkatalogs ein
standardisierter Fragebogen mit vorwiegend geschlossenen Fragen entwickelt417.
416
Vgl. Roberts (2004); Castaings et al. (2007); European Commission (2007); European Commission
(2010)
417
Der gesamte Fragebogen befindet sich im Anhang (Anhang A: Fragebogen zur explorativen
Studie). In der Folge werden jene Fragen, die für die Forschungsarbeit von primärem Interesse sind,
diskutiert.
97
Der Fragebogen enthielt neben Fragen aus dem Themenkatalog allgemeine Fragen
zum Unternehmen (Unternehmensgröße, Branche) und zur ausfüllenden Person
(Abteilung, Position im Unternehmen). Die Befragung wurde online über das Portal
Befrager.de418 im Frühjahr 2008 abgewickelt.
Für die Online-Umfrage wurden ca. 1.000 personalisierte E-Mails an Personen
österreichischer Unternehmen gesendet. Rund 170 E-Mails konnten aufgrund verschiedener Ursachen (z.B. Account existiert nicht mehr, Zielserver konnte nicht
gefunden werden,…) nicht zugestellt werden, sodass die Stichprobengröße 810
Unternehmen umfasste. Davon wurden 125 Fragebögen ausgefüllt419, was einer
Rücklaufquote von 15,4% entspricht. Da sich die Umfrage tiefgehend mit einzelnen
Aspekten zur betrieblichen Integration befasste und Fachwissen in diesem Umfeld
vonnöten war, richtete sie sich insbesondere an Personen mit EDV-/IT-Kenntnissen.
Das Vorhandensein einer Internetverbindung und einer E-Mail-Adresse wird als
Basisvoraussetzung für eine betriebliche Integration angesehen und war auch Voraussetzung, um in die Stichprobe aufgenommen zu werden.
4.1.4 Auswertung der Ergebnisse
Die Auswertung der Ergebnisse wurde mit der Statistik-Software SPSS Version 15.0
durchgeführt. Um die Hypothesen zu testen, wurde der Zusammenhang der ordinalskalierten Merkmale anhand der beiden Rangkorrelationskoeffizienten Spearman
(Spearman-Rho) und Kendall (Kendall-Tau-b) berechnet420. Da Kendall bei kleinem
Stichprobenumfang weniger empfindlich gegen Ausreißer-Rangpaare ist und Spearman in allen Korrelationen eine etwas höhere Korrelation geliefert hat, wird in
weiterer Folge nur Kendall-Tau-b angegeben. Mittels Korrelationen in Verbindung mit
Signifikanztests werden die jeweiligen Hypothesen falsifiziert bzw. nicht falsifiziert.
Zur Erklärung der Vorgehensweise bei Korrelationen sei folgendes Beispiel angegeben:
418

Hypothese: Es besteht kein Zusammenhang zwischen Variable A und B.

Ergebnis des Hypothesen-Tests: r=-,459; p < 0,01 (2-seitig).

Interpretation: Der Rangkorrelationskoeffizienten Kendall-Tau-b (r) gibt an,
dass ein negativer linearer Zusammenhang in der Höhe von -0,459 zwischen
den beiden betrachteten Variablen/Merkmalen A und B besteht. Durch das
URL: www.befrager.de, Befrager.de [16.04.2008]
419
Einige Fragen wurden durch vorherige Antworten übersprungen und nicht alle Fragen wurden
vollständig beantwortet. In den einzelnen Ergebnissen (Tabellen im Anhang) ist die Anzahl der jeweils
verarbeiteten, gültigen Fälle (N) angeführt.
420
Vgl. SPSS Inc. (2007, S. 342)
98
Signifikanzniveau (p) wird die Irrtumswahrscheinlichkeit des Zusammenhangs
ermittelt. Es ist somit ein zentraler Bestandteil der Hypothesenprüfung. Der
Zusammenhang in der angegebenen Höhe ist auf dem 1%-Niveau signifikant.
Die Hypothese, in der Grundgesamtheit bestehe kein Zusammenhang zwischen A und B, kann daher zurückgewiesen, dh. falsifiziert werden. Das Zurückweisen dieser Hypothese ist nur mit einer Wahrscheinlichkeit kleiner 1%
falsch. Die Signifikanztests wurden immer zweiseitig, dh. auf größer oder kleiner Null, durchgeführt.
Die grafische Aufbereitung der SPSS-Ergebnisse wurde mit Microsoft Office Excel
2003 vorgenommen. Die SPSS Tabellen befinden sind im Anhang. Für die Darstellung der statistischen Ergebnisse werden folgende Abkürzungen verwendet:

H:
Hypothese

r:
Korrelationskoeffizient (Kendall-Tau-b)

p, Sig:
Signifikanzniveau

N:
Stichprobengröße

Med:
Median
4.2 Ausgewählte Ergebnisse der Befragung
Die inner-, über- und zwischenbetrieblichen Voraussetzungen bzw. Rahmenbedingungen sowohl technischer als auch organisatorischer Natur werden in den weiteren
Kapiteln einer genaueren Betrachtung unterzogen. Zusätzlich werden die erwarteten
Ziele einer Integration analysiert, um den Stand von betrieblicher Integration unter
österreichischen Unternehmen einschätzen zu können. Ferner zielen die meisten
Hypothesen und Ergebnisse auf das Merkmal der Unternehmensgröße ab, um die
Unterschiede in Unternehmen verschiedener Größenordnung in der Handhabung
von betrieblicher Integration beurteilen zu können. Die Einteilung der Unternehmen
erfolgt hierbei gemäß der Europäischen Kommission aufgrund der Anzahl an Mitarbeitenden421: Kleine Unternehmen haben maximal 49 Mitarbeiter, mittelgroße Unternehmen zwischen 50 und 249 Mitarbeiter und mit mehr als 250 Mitarbeitern gilt eine
Firma als Großunternehmen. Als KMUs werden in weiterer Folge kleine und mittlere
Unternehmen mit bis zu 249 Mitarbeitern bezeichnet.
421
Vgl. Europäische Kommission (2003)
99
4.2.1 Durchführung von elektronischem Datenaustausch
Eine Integration auf Datenebene schafft meist die technischen Voraussetzungen für
eine betriebliche Integration auf weiteren Ebenen422. Besteht keine Integration auf
dieser Ebene, können keine Daten zwischen den Unternehmen fließen. Der elektronische Datenaustausch stellt daher eine wichtige konzeptuelle Ebene in der betrieblichen Integration dar, die es zu untersuchen gilt. Studien, wie die E-Business
W@tch423 auf europäischer Ebene, bezeichnen KMUs als fehlendes Bindeglied in
der Integration mit Partnern. Wenn Unternehmen Integrationen nicht eingehen,
riskieren sie durch integrationsfähigere Konkurrenten aus dem Netzwerk ersetzt zu
werden, so die Aussage der europaweiten Studie. Großunternehmen sind hierbei
weiter und setzen Integrationstechnologien zum Datenaustausch bereits in hohem
Ausmaß ein. Es wird daher angenommen, dass vor allem kleine und mittlere Unternehmen keinen elektronischen Datenaustausch durchführen. Die Hypothese (H), die
es zu untersuchen gilt, lautet daher:
H1: KMUs führen überbetrieblichen elektronischen Datenaustausch im
Vergleich zu Großunternehmen in geringerem Ausmaß durch.
Zur Überprüfung der Hypothese wurde eine Korrelation zwischen der Unternehmensgröße und der Frage „Führen Sie bereits überbetrieblichen elektronischen
Datenaustausch (dh. eine betriebliche Integration) mit Geschäftspartnern durch?“
durchgeführt. Das Ergebnis unter den befragten Unternehmen deckt sich mit den
angesprochenen Studien. Es besteht ein signifikanter Zusammenhang zwischen der
Unternehmensgröße und dem Durchführen von überbetrieblichem elektronischem
Datenaustausch (r=-,459; p < 0,01 (2-seitig)). Wie in Abbildung 23 ersichtlich, haben
66,7% der kleinen, 26,7% der mittelgroßen und 16,1% der großen Unternehmen
noch keine betriebliche Integration vorgenommen oder in Planung424.
422
Vgl. Kapitel 3.4.1
423
Vgl. European Commission (2007, S. 9); European Commission (2010, S. 11)
424
Siehe Tabelle 15 und Tabelle 16 im Anhang.
100
Abbildung 23: Auswertung der Durchführung von elektronischem Datenaustausch (dh. eine betriebliche Integration) nach Unternehmensgröße (eigene Darstellung)
Die Hypothese H1 wird also durch die Auswertung der Umfrage unterstützt, da kleine
Unternehmen signifikant weniger elektronischen Datenaustausch mit Partnern durchführen als mittlere und große Unternehmen.
4.2.2 Strategische Orientierung
Eine Strategie ist eine wichtige Voraussetzung für betriebliche Integration. Unternehmen, die etwa eine E-Business Strategie als integralen Bestandteil in ihrer Unternehmensstrategie verankert haben, können Entscheidungen in diesem Bereich
effektiver und koordinierter durchführen. Diese Unternehmen haben einen entscheidenden Vorteil bei der Umsetzung von schnell zu etablierenden, kostengünstigen
Kooperationen mit Partnern. Das Vorhandensein von schriftlichen Strategien bzw.
schriftliche Richtlinien in diesem Bereich ist demnach als Basis für die effektive
Umsetzung einer betrieblichen Integration anzusehen. Analog zur Argumentation in
den Kapiteln davor wird davon ausgegangen, dass Großunternehmen eher eine
strategische Orientierung in diesem Bereich aufweisen, was zu nachfolgender Hypothese führt.
H2: In Großunternehmen sind im Vergleich zu KMUs häufiger schriftlich
dokumentierte Strategien/Richtlinien im IT-Bereich vorhanden.
In der Umfrage wurde nach dem Vorhandensein von 10 verschiedenen schriftlichen
Strategien bzw. Richtlinien im Umfeld betrieblicher Integration gefragt. Mehrfachnennungen waren möglich. Die Antworten auf die Frage „Welche der folgenden Strategien/Richtlinien im IT-Bereich gibt es in Ihrem Unternehmen?“ wurden über Korrelationen mit der Unternehmensgröße getestet, um die Hypothese zu überprüfen. Nur
rund 12% der befragten KMUs und 33% der Großunternehmen haben demnach eine
101
schriftliche E-Business Strategie. Weitere Richtlinien wie zur Nutzung von Internet
und E-Mail, zur Handhabung sensibler Daten und zum Softwareeinsatz auf PCs
werden von etwas mehr als der Hälfte der befragten Unternehmen schriftlich festgehalten, wobei auch hier gilt: je mehr Beschäftigte das Unternehmen hat, desto eher
gibt es entsprechende Richtlinien. Im Bereich der Schulung und Weiterbildung verhält sich dies leicht anders: So haben 62,5% der mittelgroßen Unternehmen ein
entsprechendes schriftliches Konzept, allerdings nur 45,8% der Großunternehmen
und nur 16,1% der kleinen Unternehmen. In allen anderen Bereichen haben Großunternehmen gegenüber KMUs eher Dokumentationen entsprechender Richtlinien (vgl.
Abbildung 24).
Abbildung 24: Auswertung über unterschiedliche Strategien bzw. Richtlinien im IT-Bereich (Mehrfachnennung möglich) (eigene Darstellung)
Ein Zusammenhang mit der Unternehmensgröße konnte in 9 der 10 abgefragten
Richtlinien/Strategien festgestellt werden. Signifikant mehr Großunternehmen haben
Richtlinien/Strategien in folgenden Bereichen in Verwendung425:
425

Schriftliche Richtlinien zum Einsatz von Verschlüsselung und elektronischen
Signaturen (r=,405; p < 0,01 (2-seitig)),

Schriftliche Richtlinien zur Nutzung mobiler Endgeräte (Notebooks, PDAs)
(r=,400; p < 0,01 (2-seitig)),
102

Schriftliche Richtlinien zum Softwareeinsatz auf PCs (r=,358; p < 0,01 (2seitig)),

Schriftliche Richtlinien zur Nutzung mobiler Speicher (USB-Sticks) (r=,291; p <
0,01 (2-seitig)),

Schriftliche Maßnahmen zur Informationssicherheit (r=,230; p < 0,05 (2seitig)),

Schriftliche Richtlinien zur Handhabung sensibler Daten (r=,221; p < 0,05 (2seitig)),

Schriftliche Richtlinien zur Nutzung von Internet und E-Mail (r=,221; p < 0,05
(2-seitig)),

Schriftliches Schulungs- und Weiterbildungskonzept (r=,202; p < 0,05 (2seitig)) und

Schriftliche e-Business Strategie (r=,195; p < 0,05 (2-seitig)).
Richtlinien zur Nutzung serviceorientierter Architektur finden kaum explizit Anwendung und es konnte auch kein signifikanter Zusammenhang mit der Unternehmensgröße festgestellt werden.
Hypothese H2 kann durch die Auswertung nicht falsifiziert werden. Von den 10
untersuchten schriftlichen Strategien/Richtlinien im IT-Bereich konnte in 9 Fällen ein
signifikanter Zusammenhang im Sinne von „je mehr Beschäftigte das Unternehmen
hat desto eher ist eine entsprechende Strategie/Richtlinie vorhanden“ festgestellt
werden.
4.2.3 Unternehmensinterne Know-How Träger
Ein Fehlen von Know-How Trägern im Unternehmen kann zur Folge haben, dass
eine betriebliche Integration aufgrund mangelndem, technischem Integrationswissens nicht vollzogen werden kann. Da Informationstechnologie in allen Unternehmen
der Stichprobe vorhanden ist, sollten auch möglichst alle Unternehmen einen Verantwortlichen für diese Belange benannt haben426. Bedingt durch den geringeren
Personalbestand wird jedoch davon ausgegangen, dass es eher in kleinen Unternehmen keinen eigenen Spezialisten für dieses Gebiet gibt:
H3: In KMUs ist im Vergleich zu Großunternehmen häufiger kein Verantwortlicher für den IT-Bereich vorhanden.
426
Das Vorhandensein einer Internetverbindung und einer E-Mail-Adresse war Voraussetzung, um in
die Stichprobe aufgenommen zu werden. In der Umfrage wurde nicht nach dem Vorhandensein einer
IT-Abteilung sondern explizit nach einem IT-Verantwortlichen gefragt.
103
Zum Test der Hypothese wurde eine Korrelation der Frage „Ist in Ihrem Unternehmen
ein IT Verantwortlicher vorhanden?“ mit der Unternehmensgröße durchgeführt427.
Das Ergebnis zeigt, dass ein signifikanter Zusammenhang zwischen dem Vorhandensein eines IT Verantwortlichen und der Unternehmensgröße (r=,290; p < 0,01 (2seitig)) besteht. Wie in Abbildung 25 ersichtlich, beantworteten die Frage, ob ein IKT
Verantwortlicher im Unternehmen vorhanden sei, 64,3% der kleinen Unternehmen,
86,4% der mittleren Unternehmen und 92,7% der Großunternehmen mit „Ja“.
Abbildung 25: Vorhandensein eines IT Verantwortlichen in den Unternehmen (eigene Darstellung)
Die Hypothese H3 kann daher durch die Umfrage bestätigt werden, da ein signifikanter Zusammenhang zwischen dem Vorhandensein eines IT Verantwortlichen und der
Unternehmensgröße besteht. Je mehr Beschäftigte das Unternehmen hat, desto
eher gibt es einen Know-How Träger für diesen Bereich. Oftmals sind es kleinere
Unternehmen, die über keine eigenen Spezialisten verfügen.
4.2.4 Bedarf an Outsourcing
Das Outsourcen ganzer Geschäftsbereiche an Partner bei gleichzeitiger effizienter
und effektiver Nutzung der eigenen Ressourcen und Fähigkeiten stellt Unternehmen
eine Möglichkeit bereit, ihre Wettbewerbsstrategie zu realisieren. Dadurch entstehen
langfristig orientierte Wertschöpfungsnetzwerke, in denen sich einzelne Unternehmen auf ihre Kernkompetenzen konzentrieren können und bedarfsorientiert Waren
und Informationen zu diesem Zweck austauschen, um einen gesamtheitlichen Wettbewerbsvorteil zu erzielen428. Vor allem KMUs haben die Chance mittels Integration
auf Ebene der Geschäftsprozesse Teil eines innovativen und strategischen Wertschöpfungsnetzwerkes zu werden, welches das wirtschaftliche Fortbestehen im
427
428
Vgl. Kapitel 1
104
globalen Wettbewerb sichert. Daher wird angenommen, dass KMUs durch den
höheren Bedarf an Outsourcing eher einzelne Geschäftsbereiche ausgelagert haben.
H4: Der Bedarf an Outsourcing einzelner Geschäftsbereiche ist in KMUs
höher als in Großunternehmen.
Zur Überprüfung der Hypothese wurde nach Outsourcing in 11 verschiedenen Geschäftsbereichen gefragt (Mehrfachnennung war möglich) und das Ergebnis mit der
Unternehmensgröße korreliert429. Der Zusammenhang ist für die Geschäftsbereiche
Buchhaltung (r=-,300; p < 0,01 (2-seitig)), Controlling (r=-,298; p < 0,01 (2-seitig))
und Lohnverrechnung (r=-,258; p < 0,01 (2-seitig)) signifikant. Die negative Korrelation drückt aus, dass diese drei Geschäftsbereiche vor allem von kleinen Unternehmen ausgelagert werden. Den Bereich Service/Wartung haben rund 30% der befragten Unternehmen ausgelagert, wobei hier auffällig ist, dass dies rund ein Drittel der
kleinen und großen Unternehmen und nur 18,2% der mittleren Unternehmen in
Anspruch nehmen. Die weiteren Geschäftsbereiche werden generell seltener ausgelagert und es ist somit auch kein Trend für spezifische Unternehmensgrößen feststellbar (vgl. Abbildung 26).
Abbildung 26: Outsourcing unterschiedlicher Geschäftsbereiche (Mehrfachnennung möglich) (eigene
Darstellung)
Das Ergebnis zeigt, dass kleine Unternehmen vorwiegend nur innerbetriebliche
Tätigkeiten wie die Buchhaltung, Lohnverrechnung oder Controlling auslagern. Geht
429
105
es allerdings um Aktivitäten, welche direkte Tätigkeiten entlang der Wertschöpfungskette wie Produktion, Logistik oder Ein-/Verkauf sind und Gegenstand von Geschäftsprozessmanagement bzw. Supply Chain Management sind, so erkennen
überwiegend kleine Unternehmen keinen Bedarf.
Die Hypothese H4 kann aufgrund der Auswertung für die Geschäftsbereiche Buchhaltung, Controlling und Lohnverrechnung bestätigt werden. Auf weitere Bereiche
trifft sie nicht zu und wird abgelehnt.
4.2.5 Durchdringung von betrieblichen Informationssystemen
Um Daten mit Partnern austauschen zu können, sind in vielen Fällen betriebliche
Informationssysteme notwendig, die dies über Schnittstellen ermöglichen430. Ein
Fehlen von wichtigen Informationssystemen kann zur Folge haben, dass Integrationen nicht, nicht effizient oder nicht zeitgerecht vollzogen werden können. Mehraufwand für die Integration bzw. die vorherige Anschaffung (z.B. eines ERP-Systems),
um die Integration zu befähigen, ist die Folge und bedeutet zusätzliche Kosten,
Ressourcen und erhöhten Zeitbedarf. Da KMUs in ihrer Technologisierung und ihrem
IT-Einsatz gegenüber Großunternehmen oft benachteiligt sind, wird angenommen,
dass der Durchdringungsgrad von betrieblichen Informationssystemen in KMUs
ebenfalls geringer ist als in Großunternehmen.
H5: Betrachtet man die interne IT-Systemlandschaft der Unternehmen, so
sind in KMUs im Vergleich zu großen Unternehmen weniger für betriebliche Integration relevante Anwendungen und Lösungen vorhanden.
In der Umfrage wurde nach dem Vorhandensein von 13 relevanten Informationssystemen, Anwendungen und Lösungen gefragt („Welche der folgenden Anwendungen/Lösungen werden in ihrem Unternehmen eingesetzt?“). Mehrfachnennungen
waren möglich. Abbildung 27 zeigt die Antworten im Überblick.
430
Vgl. Kapitel 3.4.2
106
Abbildung 27: Einsatz unterschiedlicher betrieblicher Informationssysteme, Anwendungen und
Lösungen im Unternehmen (Mehrfachnennung möglich) (eigene Darstellung)
Das Ergebnis der Korrelation zeigt, dass bei 9 Anwendungen der Durchdringungsgrad im Vergleich zwischen großen und kleineren Unternehmen bei Großunternehmen signifikant höher ist431. Dazu zählen:
431

Software für Logistik/Lagerhaltung (r=-,461; p < 0,01 (2-seitig)),

Elektronischer Datenaustausch (EDIFACT, XML, ...) (r=-,443; p < 0,01 (2seitig)),

Elektronische Beschaffung (e-Procurement) (r=-,407; p < 0,01 (2-seitig)),

Enterprise Resource Planning (ERP) System / Warenwirtschaftssystem
(r=-,390; p < 0,01 (2-seitig)),

Artikelstammdatenverwaltung (r=-,385; p < 0,01 (2-seitig)),

Benutzung von elektronischen (B2B) Marktplätzen (r=-,311; p < 0,01 (2seitig)),

Elektronische Rechnungslegung (r=-,285; p < 0,01 (2-seitig)),

Sortimentsmanagement (r=-,231; p < 0,05 (2-seitig)),

Customer Relationship Management (CRM) (r=-,196; p < 0,05 (2-seitig)).
107
Die eigene Homepage ist sowohl für KMUs als auch für Großunternehmen mittlerweile selbstverständlich. Der eigene Online-Shop und der elektronische Katalog findet
bei kleinen Unternehmen etwas weniger Verwendung, elektronisches Marketing
ebenfalls. Diese Anwendungen korrelieren allerdings nicht signifikant mit der Unternehmensgröße.
Die Hypothese H5 kann durch die Umfrage nicht falsifiziert werden. Bei 9 der 13
untersuchten Anwendungen ist der Durchdringungsgrad im Vergleich zwischen
großen und kleineren Unternehmen bei Großunternehmen signifikant höher.
4.2.6 Standards zur betrieblichen Integration
Interoperabilität von IT-Systemen ist essentiell für betriebliche Integration und wird
durch die Verwendung von Standards vereinfacht, ja oftmals erst ermöglicht. Darüber
hinaus reduziert die Verwendung von Standards die Anpassungskosten von Schnittstellen und Integrationen können dadurch schneller, automatisierter und effizienter
vollzogen werden. Wiederum sind es vor allem die großen Unternehmen, die international gültige Standards fordern432. Es wird daher vermutet, dass die Kenntnis sowie
Verwendung einzelner Standards in Großunternehmen höher ist, als bei KMUs.
H6: Die Kenntnis und der Einsatz einzelner Standards zur betrieblichen
Integration sind in KMUs weniger stark ausgeprägt als in Großunternehmen.
Zur Überprüfung der Hypothese wurde von der Vielzahl an verfügbaren Standards
die Kenntnis von 13 im deutschsprachigen Raum relevanten Standards bzw. Klassifikationen abgefragt. Mehrfachnennungen waren möglich. Die Antworten auf die Frage
„Welche der folgenden E-Business Standards/Klassifikationen kennen Sie bzw. sind
in Ihrem Unternehmen im Einsatz?“ wurden über Korrelationen mit der Unternehmensgröße getestet, um die Hypothese zu überprüfen433. Es konnte kein signifikanter
Zusammenhang zwischen der Kenntnis eines bestimmten Standards und der Unternehmensgröße festgestellt werden, was auch auf den generell niedrigen Bekanntheitsgrad zurückgeführt werden kann.
Der mit 61,4% bekannteste und mit 25,7% am weitesten verbreitete Standard ist der
klassische, internationale EDI-Standard „UN/EDIFACT“. Auf Platz 2 landete der
Standard für Katalogmanagement „cXML“, der noch von 37,4% der befragten Unternehmen gekannt wird (Einsatz in 8,6% der Unternehmen), gefolgt von Standards des
Konsortiums „RosettaNet“ mit 30% (Einsatz allerdings nur in 2,9% der Unterneh432
Vgl. Kapitel 3.4.1
433
108
men). Alle weiteren Standards und Klassifikationen waren zwischen 74,3% („openTRANS“) und 82,9% („ProfiCl@ss“) der Unternehmen nicht bekannt (vgl. Abbildung
28).
Abbildung 28: Bekanntheit und Einsatz von Standards Klassifikationen zur betrieblichen Integration in
Unternehmen (eigene Darstellung)
Zur Überprüfung von Hypothese H6 wurde nach der Kenntnis und Verwendung von
13 relevanten Standards gefragt. Das Ergebnis zeigt keinen signifikanten Zusammenhang zwischen der Kenntnis eines Standards und der Unternehmensgröße,
weshalb die Hypothese verworfen wird.
4.2.7 Ziele einer effektiven betrieblichen Integration
Bei der Durchführung betrieblicher Integration wird meist Rationalisierung verfolgt434.
Dies kann auf unterschiedliche Weise erfolgen, wie beispielsweise durch Prozessoptimierung, Kosteneinsparung, oder Produktivitätsverbesserung. Dabei ist es unwesentlich, ob bereits eine betriebliche Integration durchgeführt wurde, oder sie sich
erst in Planung befindet.
H7: Die Anforderungen und Ziele an eine effektive betriebliche Integration
sind im Wesentlichen identisch, gleichgültig ob bereits eine Integration
umgesetzt wurde oder nicht.
434
Vgl. Kapitel 1
109
Die Unternehmen bekamen, je nachdem ob bereits eine betriebliche Integration
durchgeführt wurde oder nicht (bzw. eine in Planung befindet), eine leicht unterschiedliche Fragestellung zu den Anforderungen bzw. Zielen:

Die Frage: „Was wären/sind Ihrer Meinung nach die Anforderungen an eine
effektive betriebliche Integration?“ wurde jenen Unternehmen gestellt, die
noch keine betriebliche Integration durchgeführt oder eine geplant haben
(Gruppe „Nein” / „Geplant”).

Die Frage: „Was wollten Sie mit der betrieblichen Integration erreichen?“ wurde jenen Unternehmen gestellt, die bereits in der Vergangenheit eine betriebliche Integration umgesetzt haben (Gruppe „Ja“).
Die möglichen Antwortkategorien waren bei beiden Gruppen dieselben. Wie in Abbildung 29 ersichtlich, gaben mit insgesamt 83,7% beide Gruppen eine „Beschleunigung der Geschäftsprozesse“ als primäres Ziel an, gefolgt von „Kostensenkungen“
mit gesamt 66,2%. An dritter Stelle kam das Ziel „Qualitätsverbesserungen“ (51,2%),
gefolgt von „Interne Produktivitätsverbesserungen“ (47,9%) und „Anpassung an
Kundenwünsche“ (43,9%). Die „Erfüllung von Lieferantenanforderungen“ wurde noch
von 26,7% der Unternehmen genannt und 19% gaben an eine betriebliche Integration zur „Umsatzsteigerung“ durchgeführt zu haben bzw. durchführen zu wollen435.
435
Siehe Tabelle 27 im Anhang.
110
Abbildung 29: Anforderungen/Ziele an effektive betriebliche Integration. Vergleich von Unternehmen
mit noch nicht durchgeführter („Nein“ / „Geplant“) und bereits abgeschlossener („Ja“) Integration
(eigene Darstellung)
Vergleicht man die beiden Gruppen („Ja“ bzw. „Nein“ / „Geplant“), so lassen sich
folgende Aussagen treffen:

Die Anforderungen bzw. Ziele an eine effektive betriebliche Integration sind
nahezu die Gleichen, gleichgültig ob bereits eine Integration umgesetzt wurde
oder nicht. An erster Stelle steht die Verbesserung der Geschäftsprozesse,
danach Kostensenkungen, gefolgt von Produktivitäts- und Qualitätsverbesserungen.

Die Beurteilung der Anforderungen fällt tendenziell noch „niedriger“ aus, wenn
noch keine betriebliche Integration durchgeführt wurde. Eventuell stehen diese
Unternehmen einer betrieblichen Integration noch kritischer gegenüber, oder
haben die Chancen einer effektiven betrieblichen Integration nicht in gleichem
Ausmaß erkannt.
Wesentlich für eine ex-post Beurteilung betrieblicher Integration ist die Frage nach
der Zielerreichung, welche zusätzlich Unternehmen jener Gruppe gestellt wurde, die
bereits eine betriebliche Integration durchgeführt haben (Frage: „Wurden die definierten Ziele der Integration erreicht?“). Wie in Abbildung 30 ersichtlich, gab keines der
Unternehmen an, dass die Ziele nicht erreicht wurden und in 85,3% der Fälle wurden
111
die Ziele erfüllt. 14,7% gaben an, die Ziele „teilweise“ erreicht zu haben436. Als Gründe für die nicht vollständige Zielerreichung wurden genannt, dass entweder die
Integration noch nicht vollständig abgeschlossen ist, oder die Schnittstellen noch
nicht mit allen Kunden/Lieferanten konsolidiert sind.
Abbildung 30: Zielerreichung bei bereits erfolgter Integration (eigene Darstellung)
Das Ergebnis hat gezeigt, dass die Ziele einer betrieblichen Integration grundsätzlich
realisierbar sind und in erster Linie der Verbesserung, Optimierung und damit Beschleunigung der Geschäftsprozesse dient. Durch Integrationen werden Schnittstellen digitalisiert und sind in weiterer Folge automatisierbar, was durchgängige digitale
Prozesse mit Partnern ermöglicht. Dies wiederum führt zu einer Verbesserung der
Qualität des Prozesses und des Produktes und zu Verbesserungen der innerbetrieblichen Produktivität was laut Umfrageergebnis auch wesentliche, erreichte Ziele einer
betrieblichen Integration sind.
Wenngleich die Kosten der Anschaffung und auch die laufenden Kosten beispielsweise bei klassischen EDI Implementierungen eine maßgebliche Barriere darstellen437, führt eine betriebliche Integration in der überwiegenden Zahl der Fälle durch
die Effizienzsteigerung zu Einsparungen und einer Reduktion der Kosten. Unternehmen ist anzuraten eine Kosten/Nutzen-Rechnung durchzuführen, um die Effizienz
der betrieblichen Integration erkennen und abschätzen zu können.
Generell sind es eher Kundenwünsche als Lieferantenanforderungen, die für eine
B2B Integrationen verantwortlich sind. Dies ist vermutlich darauf zurückzuführen,
436
Siehe Tabelle 28 im Anhang.
437
Vgl. Kapitel 3.4.1
112
dass Unternehmen abnehmerseitig als Bezieher einer Leistung mehr Druck auf ihre
Lieferanten ausüben können und daher Kundenwünsche generell mehr Beachtung
finden. Können Vorgaben von Kunden nicht umgesetzt werden, so riskiert man
gegen integrations- und anpassungsfähigere Unternehmen ausgetauscht zu werden.
Die Hypothese H7 wurde aufgrund der Auswertung nicht falsifiziert. Wenngleich die
Bewertung der Ziele etwas „niedriger“ ausfällt, wenn noch keine betriebliche Integration vorgenommen wurde, sind die Hauptgründe einer effektiven betrieblichen Integration die Gleichen. Ob bereits eine Integration umgesetzt wurde oder nicht, ist
dabei nicht wesentlich. Aufgrund der geringen Anzahl an Antworten in den einzelnen
Klassen war keine weitere statistische Prüfung der Hypothese sinnvoll.
4.3 Zusammenfassung
In diesem Kapitel wurden Meinungen im Themenfeld der betrieblichen Integration
aus der gängigen Unternehmenspraxis empirisch belegt. Damit konnte die wissenschaftliche Fragestellung (FS2) beantwortet werden. Ziel der Studie ist eine Bestimmung der Praxisrelevanz betrieblicher Integration. Das Interesse und die Relevanz
unter österreichischen Unternehmen kann, wie die zentralen Ergebnisse zusammenfassend zeigen, nachgewiesen werden:

Kleine und mittlere Unternehmen (KMUs) führen signifikant weniger
überbetrieblichen elektronischen Datenaustausch mit Partnern durch als
Großunternehmen. 66,7% der kleinen, 26,7% der mittelgroßen und 16,1%
der großen Unternehmen haben noch keine B2B Integration vorgenommen
oder in Planung. Hypothese H1 wurde nicht falsifiziert.

Vor allem KMUs haben keine schriftliche E-Business Strategie und/oder
Richtlinien im Bereich der Informations- und Kommunikationstechnologien.
Von 10 untersuchten schriftlichen Strategien und Richtlinien im IT-Bereich
konnte dies in 9 Fällen bestätigt werden. Hypothese H2 wurde nicht falsifiziert.

KMUs fehlt im Gegensatz zu Großunternehmen oftmals das Know-How
im IT-Bereich. Die Frage, ob ein IT Verantwortlicher im Unternehmen vorhanden sei, beantworten 64,3% der kleinen Unternehmen, 86,4% der mittleren
Unternehmen und 92,7% der Großunternehmen mit „Ja“. Hypothese H3 wurde
nicht falsifiziert.

Der Bedarf an Outsourcing für die Geschäftsbereiche Buchhaltung (Outsourcing bei 32,1% der kleinen Unternehmen), Controlling (Outsourcing bei
32,1% der kleinen Unternehmen) und Lohnverrechnung (Outsourcing bei
46,4% der kleinen Unternehmen) ist bei KMUs signifikant höher als bei
Großunternehmen. Weitere Geschäftsbereiche werden generell seltener aus-
113
gelagert und es ist kein Trend hinsichtlich unterschiedlicher Unternehmensgröße feststellbar. Hypothese H4 wurde für diese weiteren Geschäftsbereiche
falsifiziert.

Betrachtet man die betriebliche Informationssystemlandschaft, so ist der
Durchdringungsgrad in 9 der 13 untersuchten Anwendungen im Vergleich zwischen großen und kleineren Unternehmen bei Großunternehmen signifikant höher. Die eigene Homepage hat in kleinen wie in großen
Unternehmen gleichermaßen Einzug gefunden. Der eigene Online-Shop, der
elektronische Katalog und elektronisches Marketing finden bei kleinen Unternehmen etwas weniger Verwendung. Hypothese H5 wurde nicht falsifiziert.

Durch die Verwendung von Standards können Integrationen schneller, automatisierter und effizienter vollzogen werden. Der mit 61,4% bekannteste und
mit 25,7% am weitesten verbreitete Standard ist der klassische, internationale EDI-Standard „UN/EDIFACT“. Auf Platz 2 landete der Standard für
Katalogmanagement „cXML“, der noch von 37,4% der befragten Unternehmen
gekannt und von 8,6% eingesetzt wird. Standards des Konsortiums „RosettaNet“ kennen 30% der Unternehmen, zum Einsatz kommen sie allerdings nur
noch in 2,9%. Die weiteren der insgesamt 13 abgefragten Standards und
Klassifikationen sind zwischen 74,3% („openTRANS“) und 82,9% („ProfiCl@ss“) der Unternehmen nicht bekannt. Hypothese H6 wurde falsifiziert.

Der Hauptgrund für die Durchführung einer betrieblichen Integration besteht in der „Beschleunigung von Geschäftsprozessen“ (83,7%), gefolgt
von „Kostensenkungen“ (66,2%). An dritter Stelle werden „Qualitätsverbesserungen“ (51,2%) angegeben, dicht gefolgt von internen „Produktivitätsverbesserungen“ (47,9%) und „Anpassung an Kundenwünsche“ (43,9%). Die „Erfüllung von Lieferantenanforderungen“ wird noch von 26,7% der Unternehmen
genannt und 19% geben an eine B2B Integration zur „Umsatzsteigerung“
durchgeführt zu haben bzw. durchführen zu wollen. Die Zielerreichung ist in
85,3% der Fälle gegeben, 14,7% haben die gesteckten Ziele „teilweise“ erreicht und keines der Unternehmen hat die Ziele nicht erreicht. Hypothese H7
wurde nicht falsifiziert.
Die nachfolgende Tabelle zeigt nochmals im Überblick die Befunde von allen getesteten Hypothesen.
114
Tabelle 8: Befunde der Hypothesenprüfung im Überblick
Hypothese
Inhalt
Befund
H1
KMUs führen überbetrieblichen elektronischen Datenaustausch im Vergleich zu
Großunternehmen in geringerem Ausmaß durch.
In Großunternehmen sind im Vergleich zu KMUs häufiger schriftlich dokumentierte Strategien/Richtlinien im IT-Bereich vorhanden.
In KMUs ist im Vergleich zu Großunternehmen häufiger kein Verantwortlicher
für den IT-Bereich vorhanden.
Der Bedarf an Outsourcing einzelner Geschäftsbereiche ist in KMUs höher als
in Großunternehmen.
Betrachtet man die interne IT-Systemlandschaft der Unternehmen, so sind in
KMUs im Vergleich zu großen Unternehmen weniger für betriebliche Integration
relevante Anwendungen und Lösungen vorhanden.
Die Kenntnis und der Einsatz einzelner Standards zur betrieblichen Integration
sind in KMUs weniger stark ausgeprägt als in Großunternehmen.
Die Anforderungen und Ziele an eine effektive betriebliche Integration sind im
Wesentlichen identisch, gleichgültig ob bereits eine Integration umgesetzt
wurde oder nicht.
nicht
falsifiziert
nicht
falsifiziert
nicht
falsifiziert
teilweise
falsifiziert
nicht
falsifiziert
H2
H3
H4
H5
H6
H7
falsifiziert
nicht
falsifiziert
Vorgehensmodelle in der Literatur
115
5 Vorgehensmodelle in der Literatur
Zweck des Kapitels ist die Identifikation, die Analyse und der Vergleich von relevanten Vorgehensmodellen zur Einführung, Anpassung und Integration in Unternehmen.
Das Kapitel beginnt mit der Begriffsbestimmung zum Modellbegriff und Vorgehensmodellen (Kapitel 5.1). In Kapitel 5.2 wird eine Klassifikation unterschiedlicher Vorgehensmodelle vorgenommen. Darauf aufbauend wird auf einige relevante Vorgehensmodelle im Detail eingegangen (Kapitel 5.3). Dies bildet die Basis für den anschließenden Vergleich ausgewählter Vorgehensmodelle (Kapitel 5.4). Damit wird
auch die wissenschaftliche Fragestellung (FS3) beantwortet: Welche Vorgehensmodelle aus facheinschlägiger Literatur können als strukturiertes Vorgehen bei der
betrieblichen Integration herangezogen werden? Diese Fragestellung wird mittels
Literaturrecherche und -analyse beantwortet438. Als Ergebnis der Beantwortung der
genannten Fragestellung lassen sich Anforderungen aus der Literatur und gängiger
Unternehmenspraxis an ein Vorgehensmodell zur betrieblichen Integration ableiten
(Kapitel 5.5). In Kapitel 5.6 werden die wesentlichen Ergebnisse dieses Kapitels
zusammengefasst. Der gesamte Aufbau des Kapitels ist in Abbildung 31 ersichtlich.
438
Siehe dazu auch Kapitel 2.2.1. Die durchgeführte Literaturrecherche umfasste dabei die gleichen
Literaturdatenbanken und Bibliotheken wie bereits einleitend in Kapitel 3 erläutert.
116
5.1 Begriffsbestimmung und –abgrenzung
Nach der Definition von Heinrich et al. ist ein Modell das „vereinfachende Abbild
eines Ausschnitts der Wirklichkeit […] oder eines Vorbilds für einen Teil der Wirklichkeit“ 439. In der Wirtschaftsinformatik spricht man daher verkürzt auch oft von „Modellen für Etwas“ (konstruktionsorientierter Ansatz) bzw. „Modellen von Etwas“ (abbildungsorientierter Ansatz) oder auch von Artefakten (Konstruktionen) anstelle von
Modellen440. Für eine umfassende Untersuchung des Modellbegriffs und Gegenübergestellung modelltheoretischer Ansätze sei an dieser Stelle auf die Arbeit von
Thomas verwiesen441.
Nach dem Vorgehen können Modelle weiter untergliedert werden. Ein relevanter
Vorschlag zur Klassifikation aus Sicht der Wirtschaftsinformatik findet sich in Lehner
et al., welche eine Unterteilung in „Lebenszyklus“-Modelle, Entwicklungs- und
Evolutionsmodelle, Betriebswirtschaftlich orientierte Modelle, Systementwicklungsorientierte Modelle, Personen- und kommunikationsbezogene Modelle
sowie sonstige Modelle vorgenommen haben442.
Unter den „Lebenszyklus“-Modellen werden Phasen- und Vorgehensmodelle (auch
Software Life Cycle Model), Prozessmodelle, Lebenszyklus-Modelle und Verfahrensmodelle eingeordnet. Modelle dieser Kategorie gliedern eine Gesamtaufgabe
(wie beispielsweise die Systemplanung und -entwicklung) in Teilaktivitäten und
beschreiben dessen schrittweise Verrichtung. Auf Phasenkonzepten beruhende
Vorgehensmodelle sind mittlerweile „weitgehend akzeptiert und verbreitet“443. Neben
umfangreicher Literatur zu Systemplanung und -entwicklung und zu Software Engineering gibt es zahlreiche Vorgehensmodelle für Spezialaufgaben. Hierzu ist auch
das gegenständliche Vorgehensmodell zu zählen.
Das Ziel von Entwicklungs- und Evolutionsmodellen ist es die „Unsicherheit über
den Einsatz der Datenverarbeitung zu verringern und Techniken für die Diagnose
und die Prognose des Entwicklungsstadiums zur Verfügung zu stellen“444. Modelle
dieser Kategorie sind in der Literatur auch unter Reifemodelle oder Reifegradmodelle
bekannt. Beispiele für diese Kategorie sind das Stufen-Modell nach Nolan445, das
439
440
Vgl. Strahringer (2012)
441
Vgl. Thomas (2005)
442
Vgl. Lehner et al. (1995, S. 87ff)
443
Lehner et al. (1995, S. 89)
444
Lehner et al. (1995, S. 99)
445
Vgl. Nolan (1979)
117
Modell „CMMI“ (Capability Maturity Model Integration)446 oder der internationale
Standard „SPICE“ (Software Process Improvement and Capability Determination)447
zur Beurteilung des Reifegrades von Prozessen in der Softwareentwicklung.
Systementwicklungsorientierte Modelle sind speziell für einzelne Schritte im
Software Engineering von Relevanz. Hierzu zählen Datenmodelle, Referenzmodelle,
Informationsmodelle, Objektorientierte Modelle, Integrationsmodelle, Modelle der
künstlichen Intelligenz, Lernmodelle und Modelle neuronaler Netze, Spezifikationsmodelle.
Die Kategorie der betriebswirtschaftlich orientierte Modelle beinhaltet Unternehmensmodelle, Funktionsmodelle, Prozessmodelle, Organisationsmodelle, Wirtschaftlichkeits- und Nutzenmodelle, Computergestützte Modelle zur strategischen Planung
und Übernahme von Modellen aus der Betriebswirtschaft. Als personen- und kommunikationsbezogene Modelle werden Kommunikationsmodelle, Interaktionsmodelle,
Akzeptanz- und Verhaltensmodelle, Partizipationsmodelle, Mentale Modelle und
Benutzermodelle bezeichnet. Und unter den sonstigen Modellen werden Modelle aus
Operations Research (OR-Modelle), mathematisch bzw. statistisch orientierte Modelle, Petrinetze, Simulationsmodelle und Netzwerkmodelle zugeordnet.
Für den Bereich der Systementwicklung, im Software Engineering und im Projektmanagement ist die Kategorie der Phasen- und Vorgehensmodelle innerhalb der
„Lebenszyklus“-Modelle von Interesse. Eine Definition sowie eingehende Betrachtung und Verfeinerung dieser Kategorie wird daher in weiterer Folge vorgenommen.
Die weiteren Kategorien sind für die gegenständliche Arbeit nicht von unmittelbarem
Interesse448.
Auf Basis facheinschlägiger Literatur wird nun die für die gegenständliche Arbeit
gültige und in der Folge anzuwendende Definition abgeleitet. Nach Schwarze ist ein
Vorgehensmodell folgendermaßen definiert:
„Ein Vorgehensmodell beschreibt die Art der Durchführung der Teilaufgaben einer Systementwicklung, wobei man sich meistens an der logischen oder chronologischen Reihenfolge der Aufgaben orientiert.“ 449
446
URL: http://www.sei.cmu.edu/cmmi/, Capability Maturity Model Integration (CMMI) [12.08.2011]
447
Vgl. ISO/IEC 15504:2004
448
Weitere Kategorien sind hier nicht von primärem Interesse, sind allerdings auch von Relevanz und
auch aus Gründen der Vollständigkeit angeführt. Beispielsweise kann im Zuge der Systementwicklung
die Erstellung eines (logischen und physischen) Datenmodells erforderlich sein.
449
Schwarze (2000, S. 164)
118
Schwarze stellt in seiner Definition klar, dass ein Vorgehensmodell in logische Teilaufgaben gegliedert werden sollte und sich dabei an der Reihenfolge der zu erledigenden Aufgaben orientiert. Wie dieser logische oder chronologische Ablauf der
Teilaufgaben gestaltet ist, wird von Marquardt wie folgt charakterisiert:
„Zur Durchführung von IT-Projekten sollte ein Vorgehensmodell eingesetzt werden. Es
bildet die Beschreibung der koordinierten Vorgehensweise bei der Abwicklung des Projekts und definiert sowohl den Input, der zur Abwicklung einer Aktivität notwendig ist, als
auch den Output, der als Ergebnis einer Aktivität produziert wird. Weiterhin wird eine feste
Zuordnung von Rollen, die die jeweiligen Aktivitäten ausüben, vorgenommen.“ 450
An diese beiden Definitionen anknüpfend, gehen Heinrich et al. detailliert auf die
notwendigen Komponenten und Tätigkeitsbereiche eines Vorgehensmodells ein:
„Formal gesehen der als Modell abgebildete Prozess zum Lösen eines Problems. Im Zusammenhang mit IS-Projekten die Präzisierung des Phasenmodells durch Beschreibung
(Nennung und Erläuterung) der auszuführenden Tätigkeiten und Ergebnisse der ausgeführten Tätigkeiten, der zur Ausführung der Tätigkeiten geforderten Methoden (ggf. auch
der zur Verwendung empfohlenen Werkzeuge) und ggf. auch der den Tätigkeiten zugeordneten Rollen (z.B. Projektleiter, Entwickler, Controller). Idealtypisch gesehen ist ein V.
ein standardisierter Prozess, der an eine Projektumgebung (z.B. ein Unternehmen) und
durch die Projektplanung an den jeweiligen Projektgegenstand (z.B. Konstruktion von Informationssystemen) angepasst wird. Ein V. ist i.d.R. nicht monolithisch, sondern besteht
aus Teilmodellen, die auch mehrfach verwendet und miteinander kombiniert werden können (z.B. das Teilmodell Konfigurationsmanagement). Neuerdings wird V. auch als Prozessmodell bez.“ 451
Der angesprochene Begriff des Prozessmodells („process model“) wird vor allem in
der englischsprachigen Literatur verwendet. Stellvertretend dafür sei an dieser Stelle
die Definition von Kim und Pan genannt:
“[…] a process model, the resulting “pictures of the processes”, reveals a detailed story
about the changes taking place within a target situation by explaining how objects interact,
how they collectively lead to future courses of action, and the perceived constraints on
their collective action”.452
Ein Vorgehensmodell dient also im Allgemeinen als Grundgerüst für ein strukturiertes
Vorgehen zur Lösung eines komplexen Problems, das im Zuge der Projektplanung
an die jeweilige Projektumgebung im Unternehmen angepasst wird. Damit sollen die
Anforderungen auf organisatorischer Ebene mit möglichen Lösungen auf technischer
450
Marquardt (2003, S. 921)
451
452
Kim und Pan (2006, S. 61)
119
Ebene abgeglichen werden. Dazu ist ein Vorgehensmodell meist in logische Phasen
gegliedert und enthält neben der Beschreibung der auszuführenden Aktivitäten und
Ergebnissen die im speziellen anzuwendenden Methoden und Werkzeuge sowie den
Aktivitäten zugeordneten Rollen. Im Einklang damit verwendet die Gesellschaft für
Informatik (GI) das in Abbildung 32 dargestellte Ordnungsschema zur Darstellung der
Struktur eines konkreten Vorgehensmodells und der zugehörigen Begriffswelt453. In
diesem Schema („Metastruktur“) definiert das Vorgehensmodell sowohl Regeln für
den Umgang mit dem Vorgehensmodell selbst, als auch für seine Tätigkeitsbereiche
und Komponenten. Die innerhalb des Systementwicklungsprozesses häufig aufzufindenden Tätigkeitsbereiche sind das Projektmanagement, das Konfigurationsmanagement, das Qualitätsmanagement und die Systementwicklung. Diese Tätigkeitsbereiche werden als Aktivitäten und Ergebnisse beschrieben, welche die wesentlichen Komponenten eines Vorgehensmodells bilden. Darüber hinaus legt das
Vorgehensmodell jene Methoden und Werkzeuge fest, welche die Erarbeitung von
Ergebnissen innerhalb einer Aktivität unterstützen. Ein Vorgehensmodell definiert
weiterhin spezifische Rollen, die einer Aktivität im jeweiligen Tätigkeitsbereich zugeordnet werden.
Abbildung 32: Ordnungsschema für Vorgehensmodelle der Gesellschaft für Informatik454
Das Vorgehensmodell soll die Gesamtaufgabe der Einführung von Integrationstechnologien in und zwischen Unternehmen in Teilaktivitäten gliedern. Aktivitäten werden
in Vorgehensmodellen dabei meist zu Phasen zusammengefasst. Die Verwendung
453
Vgl. Biskup und Fischer (1996)
454
Biskup und Fischer (1996, S. 3)
120
von Projektphasen verringert die Komplexität eines Projekts durch die Zerlegung in
überschaubare, zeitlich aufeinander folgende Teilaufgaben455. Ein Vorgehensmodell
dient zur genaueren Planung des Ablaufs strategisch wichtiger Projekte und damit
verbundenen Managementtätigkeiten456. Zusätzlich gibt es durch die Vorgabe von
Phasenzielen („Meilensteinen“) die Möglichkeit, Änderungen, die sich während des
Entwicklungsprozesses ergeben, rechtzeitig zu berücksichtigen sowie Fehler in
einem frühen Stadium zu erkennen und zu beseitigen457. Damit verbunden ist eine
Fortschrittskontrolle durch Meilensteine und eine projektbegleitende Qualitätssicherung.
Wie aus den Definitionen ebenfalls ersichtlich, sollte ein Vorgehensmodell zur Durchführung von Projekten, wie beispielsweise zur Einführung einer betrieblichen Integrationslösung, eingesetzt werden. Ein Projekt ist ein einmaliger Prozess mit dem Ziel
ein individuelles Ergebnis zu erzielen458. Heinrich et al. definieren ein Projekt als ein
„zielgerichtetes, klar definiertes, zeitlich begrenztes, durch Größe, Bedeutung, Komplexität, Neuartigkeit, Einmaligkeit, Kosten und Risiko aus dem üblichen Geschehen
herausragendes Vorhaben, für dessen Abwicklung eine spezifische Form der Organisation verwendet wird (vgl. DIN 69901). Das Vorliegen einzelner dieser Merkmale
reicht nicht aus; es müssen alle genannten Merkmale vorliegen.“459
Zusammenfassend wird der Begriff des Vorgehensmodells für die Arbeit folgendermaßen definiert:
Ein Vorgehensmodell ist ein Grundgerüst für ein strukturiertes Vorgehen
zur Lösung eines Problems. Im speziellen wird in der gegenständlichen
Arbeit nun der als Modell abgebildeter, standardisierter Prozess zur zielgerichteten betrieblichen Integration verstanden, der im Zuge der Projektplanung an die jeweilige Projektumgebung im Unternehmen angepasst
wird. Ein Vorgehensmodell ist in logische Phasen gegliedert und hat neben der Beschreibung der auszuführenden Aktivitäten (bzw. Tätigkeiten)
und Ergebnissen, die im speziellen anzuwendenden Methoden und
Werkzeuge sowie gegebenenfalls den Aktivitäten zugeordneten Rollen
zu beinhalten.
455
Vgl. Filß et al. (2005, S. 184)
456
Vgl. Chan et al. (2007, S. 1); Marquardt (2003, S. 921)
457
Vgl. Stahlknecht und Hasenkamp (2005, S. 217)
458
Vgl. Zwikael und Smyrk (2011, S. 2)
459
121
5.2 Überblick und Klassifikation
In diesem Kapitel soll nun eine Klassifikation unterschiedlicher Vorgehensmodelle
vorgenommen werden. Da die Geschichte von Vorgehensmodellen in der Wirtschaftsinformatik lang und vielschichtig ist, ist es nicht das Ziel der Arbeit, alle Modelle und Konzepte vollständig zu erfassen. Vielmehr soll ein Überblick über relevante
Arbeiten für den gegenständlichen Kontext gegeben werden. Allgemein lässt sich
feststellen, dass Vorgehensmodelle in der Systementwicklung und im Software
Engineering von zentraler Bedeutung sind460. Der Begriff Systementwicklung bezieht sich in der Wirtschaftsinformatik auf die Konstruktion von computergestützten
Informationssystemen461, Software Engineering bezeichnet wiederum die ingenieurmäßige Vorgehensweise bei der Software- und Systementwicklung462. Vorgehensmodelle in der Systementwicklung und im Software Engineering beschreiben somit
eine Abfolge von Aktivitäten, die zur Durchführung eines IT-Projekts erforderlich
ist463.
Vorgehensmodelle können nach Gesichtspunkten wie die Anzahl der Gestaltungsstufen, nach Systemkonzept, Umweltbezug, Richtung, Ausgangspunkt, Schwierigkeitsgrad oder auch nach der Verwendungshäufigkeit unterteilt werden. Eine Diskussion in wissenschaftlicher Literatur hat die in Tabelle 9 ersichtliche Einteilung in
genannte Gesichtspunkte hervorgebracht.
Tabelle 9: Einteilung von Vorgehensmodellen nach Gestaltungsstrategien der Systementwicklung464
Nach Anzahl der Gestaltungsstufen
Nach Systemkonzept
Nach Umweltbezug
Nach Richtung
Nach Ausgangspunkt
Nach Schwierigkeitsgrad
Nach der Verwendungshäufigkeit
Einmalig
Iterativ oder schrittweise
Datenorientiert
Inside-Out
Funktionsorientiert (an Abläufen)
Outside-In (Rahmenbedingungen
der Systemumwelt ausgehend)
Top-Down
Meet-in-the-Middle
Bottom-Up
Induktiv (Ist-Zustandsorientiert) Deduktiv (Soll-Zustandsorientiert)
Easiest-first
Hardest-first
Einfachverwendung
Mehrfachverwendung
Eine weitere Verfeinerung lässt sich hinsichtlich der Art und Weise wie das Vorgehensmodell den Weg zum Ziel beschreibt, vornehmen. Folgende Grundtypen bzw.
Ausprägungsformen können unterschieden werden:
460
Vgl. Breitner (2012)
461
Vgl. Eicker (2012b)
462
Vgl. Eicker (2012a); Sommerville (2001)
463
464
In Anlehnung an Schwarze (2000, S. 162)
122

Phasen-orientierte, „klassische“ lineare Vorgehensmodelle („sequenziell“): Modelle haben deutlich abgegrenzte Phasen, die sequentiell abgearbeitet werden (z.B. Wasserfallmodell, V-Modell)

Evolutionäre oder iterative Vorgehensmodelle („iterativ“): Prozess nimmt
inkrementelle (schrittweise) Erweiterungen und Verbesserungen vor, bis das
System bzw. die Software lauffähig (für Test- oder Produktivbetrieb) ist. Gegebenenfalls kommt Prototyping zum Einsatz (z.B. prototyping-orientiertes
Life-Cycle-Modell)

Agile Vorgehensmodelle („agil“): Ein stufenweises Entwickeln in kleinen
Schritten (ca. 3-4 Wochenzyklen) soll die Reaktionsfähigkeit und Flexibilität
erhöhen (z.B. Scrum Prozess-Modell)
Diese Vorgehensmodelle werden in der Software- und Systementwicklung eingesetzt. Die linearen Vorgehens- oder Phasenmodelle sind zeitlich betrachtet die
Ältesten. Als eine erste wissenschaftliche Veröffentlichung im Bereich des Software
Engineering ist die Arbeit von Benington aus dem Jahr 1956 zu nennen465. Benington
charakterisiert dabei den Softwareentwicklungsprozess von großen Softwareprodukten als streng sequentiellen Ablauf. Dieses Stufenmodell wird 1970 von Royce um
Rückkopplungen erweitert und als Wasserfallmodell bekannt466. Die grundsätzlich
sequentielle Vorgehensweise in den Phasen Anforderungsplanung (System und
Software), Analyse, Entwurf, Programmierung, Test und Betrieb bleibt die Basis für
Softwareentwicklungsprojekte in der Industrie und in Behörden zu dieser Zeit. Ende
der 70er Jahre stellt Boehm den einzelnen Phasen des Wasserfallmodells zur Qualitätsprüfung Schritte der Verifikation und Validierung gegenüber und begründet damit
das V-Modell467. Das V-Modell (seit Feb. 2005 als „V-Modell XT“ bezeichnet468) ist
mittlerweile ein weitverbreitetes und anerkanntes Modell für die Planung und Durchführung von Softwareentwicklungsprojekten ua. der öffentlichen Hand in Deutschland. Das V-Modell wurde unabhängig vom Einsatzbereich konzipiert und bedarf
daher einer Anpassung an die jeweiligen Unternehmenskontext („Tailoring“). Neben
dem Teilmodell der Softwareentwicklung enthält es zudem Submodelle für das
Projektmanagement, die Qualitätssicherung und das Konfigurationsmanagement469.
Durch die streng sequentielle Vorgehensweise der Wasserfallmodelle in abgeschlossenen Phasen entstehen Risiken vorwiegend gesammelt am Schluss der Entwick465
Vgl. Benington (1987)
466
Vgl. Royce (1987)
467
Vgl. Boehm (1979)
468
Weiterführende Informationen finden sich auf den V-Modell-Seiten der IndustrieanlagenBetriebsgesellschaft mbH (IABG), URL: www.v-modell.iabg.de [30.05.2011]
469
Vgl. Hansen (1998, S. 147)
123
lung („Big Bang“). Zusätzlich gehen Wasserfallmodelle von vollständig ausgearbeiteten Dokumentationen in der Analyse bzw. beim Entwurf aus, was in Projekten mit
zunehmender Benutzer-Interaktion und Partizipation zu Problemen führt470. Aufgrund
seiner Erfahrungen in Projekten ist es auch Boehm der Ende der 1980er Jahre das
Spiralmodell begründet471. Durch das iterative Vorgehen und das sich wiederholende Betrachten der Phasenergebnisse sollen hohe Änderungsaufwände und das
Risiko des Scheiterns verringert werden. Neben der Risikoanalyse ist die Erstellung
und Evaluierung von Prototypen zentrales Element dieses Modells. Die Anordnung
der sich wiederholten Tätigkeiten in vier Quadranten liefert dem Modell das typische
Spiralmuster. In mehreren Intervallen wird das System schrittweise ausgebaut, bis
der Prototyp zu einem finalen, betriebsbereiten System herangereift ist. Man spricht
daher auch von einem evolutionären Modell472. Der Begriff des „Prototyping“ tauchte
im Bereich der Softwareentwicklung auch bereits Ende der 1970er Jahre in wissenschaftlichen Publikationen auf473 und fand Einzug in anerkannten Vorgehensmodellen wie beispielsweise das prototyping-orientierte Life-Cycle-Modell474. Durch Prototypen können Benutzer eine lauffähige Vorversion des geplanten Systems bereits in
einer frühen Phase erproben. Fehler können mittels Prototypen schneller aufgedeckt
und auf geänderte Benutzerbedürfnisse schneller reagiert werden.
Die bewusste Reduktion von Komplexität durch eine stufenweise Entwicklung und
eine möglichst rasche Reaktion auf sich ändernde Bedürfnisse sind Prinzipien von
agilen Vorgehensmodellen. Durch ein frühes Einsteigen in die Codierung, starke
Einbeziehung der Nutzer, beständiges Testen und die kontinuierliche Weiterentwicklung der Architektur versprechen agile Modelle eine höhere Flexibilität475. Bekannteste Vertreter dieser Typen sind Extreme Programming (XP)476 und Scrum477. Obwohl
erst Ende der 1990er Jahre entstanden, greifen diese ebenfalls auf die Techniken
evolutionärer, prototyping-orientierter Vorgehensweisen zurück478.
470
Vgl. Schmietendorf et al. (2002, S. 211)
471
Vgl. Boehm (1988)
472
Vgl. Hansen (1998, S. 140)
473
Vgl. Bally et al. (1977); Naumann und Jenkins (1982); Alavi (1984)
474
Vgl. Pomberger und Weinreich (1994)
475
Vgl. Kuhrmann (2012)
476
Vgl. Beck (2000)
477
Vgl. Schwaber und Beedle (2002)
478
Vgl. Morien et al. (2008)
124
5.3 Relevante Vorgehensmodelle im Detail
Im vorherigen Kapitel wurde die Kategorie der Phasen- und Vorgehensmodelle (in
weiterer Folge als „Vorgehensmodelle“ bezeichnet) als relevante Zielkategorie für die
gegenständliche Arbeit identifiziert. Ferner wurde festgestellt, dass Vorgehensmodelle in der Systementwicklung und im Software Engineering eine hohe Bedeutung
haben. Dieses Kapitel dient nun dazu, einen detaillierteren Einblick in Phasen, Aktivitäten und Abläufe von relevanten Modellen aus facheinschlägiger Literatur und
gängiger Unternehmenspraxis zu geben. Die ausgewählten Vorgehensmodelle sind
wissenschaftlich fundiert und/oder in der Unternehmenspraxis häufig anzutreffen und
wurden deshalb als relevant für die gegenständliche Arbeit angesehen.
5.3.1 Wasserfallmodell
Das Wasserfallmodell ist ein sequentielles Vorgehensmodell, das die
Projekttätigkeiten in aufeinanderfolgende Phasen einteilt. Die Ergebnisse einer
Phase fliessen immer in die darauf folgende Phase, wobei von vollständigen
Ergebnissen vor dem Start einer neuen Phase ausgegangen wird. Es existieren
verschiedene Ausprägungen des Wasserfallmodells. Als das bekannteste und
einfussreichste Modell gilt das Wasserfallmodell nach Boehm479, welches auf der
Basis von Royce erstellt und erweitert wurde (siehe Abbildung 33). Das Modell
schliesst die einzelnen Phasen mit einem Meilenstein ab. Eine zeitlich parallele
Ausführung von Aktivitäten in Phasen ist nicht vorgesehen. Rückkopplungen in die
jeweils vorangegangene Phase sind möglich, nicht jedoch über mehrere Phasen
hinweg.
479
Vgl. Boehm (1988, S. 62)
125
Abbildung 33: Wasserfallmodell von Boehm nach Royce480
5.3.2 Das klassische sequenzielle Phasenmodell der Softwareentwicklung
Das klassische sequenzielle Phasenmodell481 beruht ebenfalls auf dem idealisierten
Prinzip, dass eine Phase erst dann bearbeitet werden darf, wenn die vorhergehende
Phase vollständig abgeschlossen ist. Rückkopplungen sind nicht vorgesehen. Das in
Abbildung 34 dargestellte Modell zeigt die Phasen und Ergebnisse des Software Life
Cycle, das ist die Zeitspanne in der ein Software-Produkt geplant, entwickelt, eingesetzt und weiterentwickelt wird, bis zum Ende seiner Nutzung.
480
481
Boehm (1988, S. 62)
Vgl. Pomberger und Pree (2004, S. 11–17) (in Pomberger und Blaschek (1996, S. 18–23) als
„Software-Life-Cycle-Modell“ bezeichnet)
126
Abbildung 34: Sequenzielles Phasenmodell482
Ausgehend von einer Projektidee beginnt der Lebenszyklus eines SoftwareProduktes mit einer Analyse- und Grobplanungsphase. Das Ergebnis dieser Phase
ist eine grobe Beschreibung des Ist-Zustandes in Form eines Lastenheftes und eines
ersten Projektplanes. In der zweiten Phase wird in einem Pflichtenheft (auch Systemspezifikation oder Anforderungsspezifikation genannt) festgelegt, was das geplante Software-Produkt leisten soll. Zusätzlich wird eine detaillierte Projektplanung
vorgenommen. Das Ziel der Phase 3, der Entwurfsphase, ist es zu spezifizieren,
welche Systemkomponenten die im Pflichtenheft dokumentierten Anforderungen
abdecken und wie diese zusammenarbeiten sollen. Die vierte Phase bringt die entworfenen Komponenten in eine auf einem Rechner ausführbare Form und unterzieht
diesen einen Komponententest. Tätigkeiten in dieser Implementierungsphase sind
etwa die Übertragung von Algorithmen in eine Programmiersprache oder die Überführung eines logischen Datenmodells in eine physische Datenbank. Im anschließenden System- und Integrationstest werden die Komponenten zusammengeführt
und unter realen Bedingungen geprüft. Das Ergebnis dieser Phase ist ein einsatzfähiges Softwaresystem, welches zur Benutzung freigegeben wird. Fehler, die während
des Betriebs der Software auftreten, sind im Zuge der Software-Wartung zu beheben. Neben den Aktivitäten in den einzelnen Phasen bilden die Dokumentation und
482
Pomberger und Pree (2004, S. 12)
127
die Qualitätssicherung wichtige Tätigkeiten, die projektbegleitend, also über alle
Phasen hinweg, durchzuführen sind483.
5.3.3 Spiralmodell
Das Spiralmodell nach Boehm484 ist ein iteratives Vorgehensmodell für die Softwareentwicklung, welches als evolutionärer Prozess gesehen wird485. Im Modell werden
einerseits der Gesamtaufwand und andererseits der Projektfortschritt in den einzelnen Spiralzyklen dargestellt. Die Spirale teilt sich in vier Quadranten, die mehrmals in
sich wiederholenden Schleifen durchlaufen werden486. Im ersten Quadranten werden
Ziele, Lösungsvarianten, Nebenbedingungen und Einschränkungen festgelegt. Die
Beurteilung der Lösungsvarianten sowie das Erkennen und Beseitigen von Risiken
ist Inhalt des zweiten Quadranten („Risikoanalyse“). Der dritte Quadrant beinhaltet
die Entwicklung und Validierung des Produkts und der vierte Quadrant umfasst die
Planung der nächsten Phasen des Zyklus. Neben der Risikoanalyse zur Absicherung
der weiteren Entwicklung ist die Erstellung und Überprüfung von Prototypen zentrales Element im Spiralmodell. Durch den Einsatz von Prototypen können die Risiken
kontinuierlich evaluiert und bei einem Auftreten von Problemen rasch reagiert werden.
5.3.4 Das Prototyping-orientierte Prozessmodell
Das Prototyping-orientierte Prozessmodell487 versteht sich als Ergänzung zum klassischen phasenorientierten Vorgehen, wie beispielsweise im Wasserfallmodell. Es
handelt sich um ein iteratives Modell, in dem mehrmalige Wiederholungen nicht nur
möglich, sondern explizit notwendig sind. Die grundsätzliche Phaseneinteilung findet
sich auch in diesem Modell wieder, allerdings mit zeitlich stark überlappenden Phasen der Problemanalyse und Spezifikation mit einem Prototyp der Benutzerschnittstelle. Die daran anschließenden Phasen Entwurf, Implementierung und Test sind
ebenfalls stark verwoben, sodass es keine vollständige Trennung wie im klassischen
Phasenmodell gibt. In diesen Phasen wird ebenfalls in mehreren Zyklen ein Prototyp
entwickelt488.
483
Vgl. Pomberger und Pree (2004, S. 12–14)
484
Vgl. Boehm (1988)
485
Vgl. Hansen (1998, S. 140)
486
Vgl. Pomberger und Blaschek (1996, S. 27)
487
Vgl. Pomberger und Pree (2004, S. 26–32) (in Pomberger und Blaschek (1996, S. 24–26) noch als
prototypingorientiertes Life-Cycle-Modell bezeichnet)
488
128
Abbildung 35: Prototyping-orientiertes Life-Cycle-Modell nach Pomberger489
Durch die Überlappung der einzelnen Phasen mit der Erstellung von lauffähigen
Prototypen soll das Risiko, eine Fehlentscheidung zu treffen, verringert werden490.
Der Lerneffekt durch Experimente unter realen Bedingungen, der mit den Prototypen
erzielt werden kann, erleichtert zudem die Qualitätssicherung491.
5.3.5 Phasenmodell in der Systemplanung
Nach Heinrich und Burgholzer492 ist die Einführung von betrieblichen Informationssystemen im Gesamtkontext strategischer Planung zu sehen. Die Grundlage bildet
das strategische Projektportfolio, welches die Ziele für die zukünftige Informationsinfrastruktur unter Berücksichtigung bereits vorhandener Informationssysteme vorgibt.
Das weitere Vorgehen erfolgt in den fünf Phasen Vorstudie, Feinstudie, Entwurf,
Implementierung und Installierung mit jeweils einem definierten Zwischenergebnis.
Der Output einer Phase bildet zugleich den Input für die darauffolgende Phase. Die
Phasen folgen dabei aber keinem linearen Ablauf, sie überlappen sich und durch
Rückkopplungen kann es zu mehreren Entwicklungszyklen kommen. Der gesamte
489
Pomberger und Weinreich (1994, S. 527)
490
491
Vgl. Pomberger und Weinreich (1994, S. 527)
492
Vgl. Heinrich und Burgholzer (1994)
129
Ablauf wird von phasenübergreifenden Aufgaben wie Testen, Dokumentieren und
Qualitätssicherung begleitet.
5.3.6 Vorgehensmodell der Systementwicklung nach Stahlknecht und
Hasenkamp
Auch Stahlknecht und Hasenkamp orientieren sich in ihrem Vorgehensmodell der
Systementwicklung gängigen Phasenmodellen. Dabei berücksichtigen sie sowohl
den Fremdbezug von Standardsoftware als auch die Eigenentwicklung von Individualsoftware. Das Modell startet mit der Vorphase „Projektbegründung“, in der das
Projekt definiert und durch einen Auftrag offiziell gestartet wird. Besondere Bedeutung schreiben die Autoren der Analyse zu, da oftmals erst am Ende dieser Phase
entschieden wird, ob das System realisiert werden soll. Unter Berücksichtigung der
Ist-Analyse und des Sollkonzeptes wird zusätzlich entschieden, ob eine Eigenentwicklung von (Individual-)Software oder die Anschaffung von Standardsoftware
weiter verfolgt werden soll. Beide Möglichkeiten bedingen eine Entwurfs-, Realisierungs- und Einführungsphase493.
Abbildung 36: Vorgehensmodell der Systementwicklung nach Stahlknecht und Hasenkamp494
493
Vgl. Stahlknecht und Hasenkamp (2005, S. 217)
494
Stahlknecht und Hasenkamp (2005, S. 218)
130
5.3.7 Vorgehensmodell der Systementwicklung nach Schwarze
Das Vorgehensmodell der Systementwicklung nach Schwarze495 bindet mittels
Prototyping den Anwender in die einzelnen Phasen der Systementwicklung mit ein.
Das Modell ist in die fünf Hauptphasen Initialisierung, Analyse, Entwurf, Realisierung
und Systemnutzung unterteilt und beinhaltet phasenübergreifende Tätigkeiten zum
Projektmanagement, Qualitätsmanagement und Entwicklungsdokumentation (siehe
Abbildung 37). Die Phasen sind darüber hinaus in einzelne Aktivitäten unterteilt.
Rückkopplungen in die jeweils vorhergehende Phase wie beim Wasserfallmodell (vgl.
Kapitel 5.3.1) sind bis zur Systemnutzung vorgesehen und führen während der
Initialisierungsphase zum Abbruch des Projekts.
Abbildung 37: Vorgehensmodell der Systementwicklung nach Schwarze496
5.3.8 oose Engineering Process (OEP)
Der oose Engineering Process (OEP) ist ein iteratives Vorgehensmodell für die
Softwareentwicklung. OEP wurde im Jahre 1996 von Oestereich in Leben gerufen.
Die derzeit aktuelle Version 3.0 stammt aus dem Jahr 2006. OEP richtet sich an die
Praxis und wird auch kommerziell vertrieben. Dem OEP liegt ein Phasenmodell mit
fünf Hauptphasen zu Grunde, welches eine iterativ-inkrementelle Vorgehensweise
ermöglicht (siehe Abbildung 38)497.
495
Vgl. Schwarze (2000, S. 164ff)
496
Schwarze (2000, S. 166)
497
Vgl. Oestereich (2007, S. 15)
131
Abbildung 38: OEP Phasenmodell498
Durch die Einteilung in Phasen wird der Entwicklungsprozess in eine zeitliche Abfolge gebracht. Diese Einteilung ist zugleich die einzige, die streng sequenziell definiert
ist. Vor allem die Entwurfs- und die Konstruktionsphase werden iterativ abgewickelt.
Am Ende jeder Phase definiert genau ein Meilenstein die zu erreichenden Ergebnisse. In der ersten Phase, der Vorbereitungsphase, gilt es das Problem zu verstehen
sowie eine Basis für die Projektplanung und -durchführung zu schaffen. Die nachfolgende Entwurfsphase (oder auch „Startphase“ genannt) dient dazu, den Lösungsansatz zu verstehen und abzusichern und zur Festlegung der Architektur. In der dritten
Phase, der Konstruktionsphase (oder „Hauptphase“) wird die Lösung entwickelt. Die
Entwicklung der Software erfolgt schrittweise (Analyse, Design, Implementierung,
Test etc.). Die Einführungsphase sieht neben dem endgültigen Test und Abnahme in
der Zielumgebung Schulungen und die Inbetriebnahme vor. Die Anwendung der
fertiggestellten Lösung erfolgt in der Betriebsphase499.
5.3.9 Accelerated SAP (ASAP)
Das Unternehmen SAP500 mit Hauptsitz in Deutschland ist einer der weltweit größten
Softwarehersteller zur Abwicklung von Geschäftsprozessen in Unternehmen. Accelerated SAP (ASAP) ist die von SAP empfohlene Implementierungsmethode für einzelne Unternehmen. ASAP beschreibt dabei die Vorgehensweise bei der Einführung
498
URL: http://www.oose.de/oep, oose Engineering Process (OEP) [04.07.2011]
499
Vgl. Oestereich (2007, S. 17–31)
500
URL: www.sap.com, SAP AG [30.06.2011]
132
von SAP-Software im Unternehmen. Für die vorgelagerte Phase der strategischen
Planung und Evaluierung findet die „Customer Solution Strategy“ Anwendung. Für
die nach der Einführung der Software mittels ASAP nachgelagerte Phase im Lebenszyklus, die kontinuierliche Verbesserung, wurde die Methodik „Continuous Business
Improvement (CBI)“ entwickelt501.
ASAP beinhaltet einen Projektplan (die in Abbildung 39 dargestellte Roadmap), eine
Beschreibung, welche Aktivitäten warum und wie auszuführen sind. Dabei handelt es
sich um ein Phasenmodell, angelehnt an das klassische sequenzielle Phasenmodell
der Softwareentwicklung (vgl. Kapitel 5.3.2). Mittels sogenannter „Accelerators“ soll
Unternehmen mithilfe von Beispielen, Checklisten und Vorlagen ein schnellerer
Einstieg in einzelne Aktivitäten bei der Implementierung geboten werden. Zusätzlich
bietet SAP Werkzeuge für das Projektmanagement sowie den Support in Form von
Consulting, Trainings und Schulungen während der Implementierung an502.
Abbildung 39: Die Phasen der Methodik „Accelerated SAP“503
Ein Accelerated SAP Projekt erstreckt sich über die fünf Phasen Projektvorbereitung,
Sollkonzeption, Umsetzung, Produktionsvorbereitung und Produktivstart. Die Phase
der Projektvorbereitung („Project Preparation“) konzentriert sich auf die Organisation
des Projekts. Neben den Projektzielen und einer allgemeinen Vorgehensweise zu
Erreichung dieser wird das Projektteam zusammengestellt und der Projektauftrag
erstellt. Das Ziel der Phase 2, der Sollkonzeption („Business Blueprint“), ist es die
Anforderungen an das System zu definieren. In Interviews, Workshops und mittels
Umfragen wird festgelegt, welche Geschäftsprozesse umzusetzen sind. Ergebnis
dieser Phase ist ein Sollkonzept, der Business Blueprint Report. Das Hauptziel der
dritten Phase ist die eigentliche Konfiguration und Anpassung des Systems
(„Customizing“). In der vierten Phase, die Produktionsvorbereitung („Final Preparation“), erfolgt die endgültige Vorbereitung des Systems auf die Produktivphase. Dazu
501
Vgl. Gulledge und Simon (2005, S. 715)
502
Vgl. Gulledge und Simon (2005, S. 714)
503
Gulledge und Simon (2005, S. 716)
133
gehören etwa Systemtests, Endbenutzer-Schulungen und die Datenmigration. Im
fünften Schritt wird das System offiziell für den Produktivstart freigegeben. Danach
wird das System aus der Sicht der Geschäftsprozesse, aus technischer Sicht und
aus Sicht der Endbenutzer evaluiert und so ein Prozess zur kontinuierlichen Verbesserung angestoßen504.
5.3.10
Methodik zur Service-orientierten Entwicklung
Papazoglou und van den Heuvel entwerfen eine Vorgehensweise zum Design und
zur Entwicklung von service-orientierter Software505. Die Methodik folgt einem iterativ-inkrementellen Prozess in 6 Hauptphasen, mit Fokus auf eine Unterstützung von
Geschäftsprozessen.
Die Methodik beginnt mit einer vorgelagerten Planungsphase. In dieser werden
vorbereitende Tätigkeiten zur Organisation der nachfolgenden Phasen sowie die
Machbarkeit geprüft und Ziele, Regeln, Verfahren und erste Anforderungen festgelegt. Die Analysephase basiert auf einer gründlichen Business Case Analyse, die
unterschiedliche Alternativen zur Unterstützung von Geschäftsprozessen beinhaltet.
Die Design-Phase zielt auf die Identifikation und schrittweise Spezifikation von Web
Services ab. Die Grundlage hierfür bilden die Geschäftsprozesse bzw. -szenarien. In
der daran anschließenden Phase („Construction and Testing“) werden Web Services
und Geschäftsprozesse auf Basis des Designs entwickelt und getestet. Das Testen
beinhaltet sowohl eine Prüfung auf funktionale Korrektheit und Vollständigkeit als
auch einen Test auf Interoperabilität. Die anschließende Phase „Provisioning“ setzt
das Geschäftsmodell für die Bereitstellung von Services und Diensten, welches in
der Planungsphase ausgearbeitet wurde, in die betriebliche Praxis um. Danach
können die entwickelten Services in den Echtbetrieb überführt werden („Deployment“). Die letzte Phase der Methodik beschäftigt sich mit der Ausführung der Services und Überwachung ihres Lebenszyklus506.
504
Vgl. Gulledge und Simon (2005, S. 715–717)
505
Vgl. Papazoglou und van Den Heuvel (2006)
506
Vgl. Papazoglou und van Den Heuvel (2006, S. 420–440)
134
Abbildung 40: Phasen im Service-orientierten Entwurf und Implementierung507
5.3.11
Projektablauf beim Business Engineering
Gemäß Österle betrifft das Business Engineering die Ebene der Geschäftsstrategie,
die Prozess-Ebene sowie die Informationssystem-Ebene. Nur durch die Berücksichtigung aller drei Ebenen können Innovationen in Unternehmen wirksam vorangetrieben werden. Die Prozessentwicklung dient als Bindeglied zwischen der Strategieund IS-Entwicklung, dh. der Prozess wird als Schlüssel zum Business Engineering
gesehen. Betrachtet man den Projektablauf beim Business Engineering, so erfordert
dieser zuerst ein Projekt (dh. eine „Revolution“) und dann die Weiterentwicklung (als
„Evolution“ bezeichnet) durch die Prozessführung (siehe Abbildung 41). Die Abwicklung als Projekt ermöglicht eine gründliche Vorbereitung und planbare Durchführung
der Veränderungen. Dem Projekt muss eine laufende Verbesserung des Prozesses
durch Verbesserung aufgrund Erfahrungen im Routinebetrieb, Ausrichtung an vereinbarten Zielen und Anpassung an veränderte geschäftliche Rahmenbedingungen
folgen508.
507
Papazoglou und van Den Heuvel (2006, S. 416)
508
Vgl. Österle (1995, S. 14ff)
135
Abbildung 41: Revolution und Evolution im Business Engineering509
Österle merkt weiterhin an, dass Business Engineering grundsätzlich top down von
der Strategie über den Prozess zum Informationssystem abläuft. In der Praxis kann
ein Projekt allerdings auch auf einer anderen Ebene als der Geschäftsstrategie
gestartet werden, was ebenso zu erfolgreichen Projekteergebnissen führt. Wichtig ist
jedoch, dass Projekte nicht isoliert betrachtet werden, sondern alle drei Ebenen des
Business Engineering (Strategie, Prozess, Informationssystem) einbezogen werden510.
5.3.12
Vorgehensweise im Business Networking
Unter Business Networking wird das Management der Beziehungen zu Lieferanten
und Kunden verstanden. Business Networking wird von den Autoren als ein zentrales
Geschäftskonzept für Unternehmen im Internet-Zeitalter gesehen, in dem die Kundenorientierung durch Netzwerkfähigkeit und Services im Mittelpunkt steht. Unternehmen müssen die Fähigkeit besitzen, schnell und effizient Beziehungen zu Geschäftspartnern aufzubauen (Netzwerkfähigkeit) und informationsbasierten Mehrwert
durch Services anzubieten, um ihnen maßgeschneiderte Lösungen zu günstigen
Kosten und in hoher Qualität anzubieten511.
Zum Auf- und Ausbau der Netzwerkfähigkeit von Unternehmen identifizieren Alt et
al.512 ein Vorgehen in vier Phasen. In der ersten Phase („Analyse von Kooperations509
Österle (1995, S. 23)
510
Vgl. Österle (1995, S. 24)
511
Vgl. Alt und Österle (2000)
512
Vgl. Alt et al. (2000a)
136
potentialen“) wird zuerst eine Analyse durchgeführt, um die profitabelsten Bereiche
für Business Networking ausfindig zu machen. Dies passiert oft in Verbindung mit
einer kurzen Vorstudie (2-3 Wochen). Das Ergebnis dieser Phase ist ein Kooperationskonzept, das dem Top Management präsentiert wird. Sofern das Management
eine Entscheidung zugunsten des Konzeptes trifft, werden in der zweiten Phase
(„Design und Evaluierung von Szenarien“) spezifische Alternativen entwickelt und
evaluiert. Diese Phase wird gemeinsam mit dem Kooperationspartner durchgeführt
und führt zu einem Kooperationsvertrag. Basierend auf dem Kooperationsvertrag
werden in der dritten Phase einzelne Pilotprojekte geplant und durchgeführt. In
dieser Phase kommen die Implementierungsmethoden der Systemhäuser (wie z.B.
das in Kapitel 5.3.9 beschriebene SAP ASAP) zum Einsatz. In der vierten Phase wird
über die Weiterführung der Pilot-Anwendung entschieden. Dies erfolgt in Abhängigkeit vom Erfolg der Pilotprojekte und anderen Kriterien. Mögliche Entscheidungen
sind:

Roll-out der Lösung auf andere Organisationseinheiten

Einstellung des Pilot-Betriebes, und/oder

andere Kooperationsprojekte weiter verfolgen.
Abbildung 42: Vorgehen im Business Networking513
513
Alt et al. (2000a, S. 271)
5.3.13
137
ISM-Vorgehensmodell
Paulzen und Haas514 beschreiben die Möglichkeiten der Einbeziehung von internem
und externem Wissen im Kontext von Lieferantenmanagement. Die Ergänzung der
Sichtweise des Business Intelligence (BI) um Methoden aus dem Wissensmanagement definieren sie dabei als „Intelligent Supplier Management“ (ISM). Für ein strukturiertes Vorgehen in einem ISM Gesamtprojekt entwerfen die Autoren das in Abbildung 43 dargestellte Vorgehensmodell.
Abbildung 43: ISM-Vorgehensmodell515
Dem ISM-Vorgehensmodell liegt ein Phasenmodell mit vier Hauptphasen zu Grunde,
wobei die letzteren drei Phasen eine Rückkopplung über Feedback erlauben. Die
erste Phase lässt keine Rückkopplung aus späteren Phasen zu, da diese vor der
eigentlichen Projektplanung ausgeführt wird. Diese als ISM-Vorstudie bezeichnete
Phase dient zur Sensibilisierung der Geschäftsführung und der Einkäufer, zur Aufdeckung von Potentialen, zur Festlegung der Strategie und zur Zieldefinition. Die ISMVorstudie teilt das Gesamtprojekt in mehrere Einzelprojekte auf, die es in der zweiten
Phase, der ISM-Lösungsplanung, zu priorisieren und zu planen gilt, da die aufgezeigten Projekte in der Regel nicht parallel durchgeführt werden können. Die Autoren
empfehlen daher, mit jenen Projekten zu beginnen, die sich aus Kosten-/Nutzensicht
am vielversprechendsten erweisen. Als Hilfsmittel in dieser Phase wird die Portfolioanalyse genannt, mit derer einzelne Projekte in Bezug auf ihre Realisierbarkeit und
ihre Nutzenpotentiale priorisiert werden können.
514
Vgl. Paulzen und Haas (2002)
515
Paulzen und Haas (2002)
138
Phase 3 beschreibt die Implementierung der ISM-Projekte. Hierfür ist jedes einzelne
Projekt individuell zu planen und daran anschließend in den Phasen Analyse, Design, Implementierung und Test mittels Prototyping umzusetzen. Der Prototyp wird
einem Probe- oder Echtbetrieb zugeführt und in der Folge weiterentwickelt. Die
Aufteilung in einzelne, kleinere Projekte mit einer Prototyping-orientierten Umsetzung
hat den Vorteil, dass es rasch vorzeigbare Ergebnisse liefert („Quick Wins“). Ebenso
betonen die Autoren die Notwendigkeit, eine ausschließliche Betonung technischer
Komponenten zu verhindern und die nötigen Wissensperspektiven des Analyseframeworks im Auge zu behalten („think big, start small“). Das Analyseframework
unterscheidet nach dem Bezug der Wissensträger zum Unternehmen in internes/externes Wissen und nach dem Grad der Personengebundenheit in implizites/explizites Wissen. Explizites Wissen ist beschreibbares Wissen, welches sich
relativ einfach speichern, verarbeiten und verteilen lässt. Es liegt entweder in strukturierter Form (z.B. in ERP-Systemen) oder unstrukturierter Form (z.B. in Dokumenten
oder Webseiten) vor.
Die Phase 4 dient zur Optimierung der ISM-Projekte sowie zur Überprüfung der Ziele
und der Strategie. Während des gesamten ISM-Vorgehensmodells ist ein MultiProjektmanager für die Koordination zuständig. Ein kompetentes Qualitätsmanagement und Change Management werden ebenfalls als phasenübergreifende Erfolgsfaktoren genannt. Darüber hinaus sind innovative Organisationsformen (z.B. Prozessorientierung und Aufgabenintegration im Rahmen der Einkaufsprozesse), Motivation der Mitarbeiter (z.B. Anreizsysteme für qualitativ hochwertigen Input in die
Communities) und Maßnahmen, die auf eine Veränderung der Unternehmenskultur
abzielen (z.B. Etablierung einer änderungsfreundlichen Unternehmenskultur) notwendige Bausteine im Vorgehen. Diese sollen vor allem eine Überbetonung von rein
technischen Aspekten wirkungsvoll verhindern.
5.4 Synoptischer Vergleich ausgewählter Vorgehensmodelle
Die im vorangegangenen Kapitel diskutierten Vorgehensmodelle zur Software- und
Systementwicklung sollen nun gegenübergestellt werden. Wenngleich die Gliederung
und die Bezeichnungen von Arbeitsabschnitten variieren, soll ein Grundmuster
erkannt werden, das dem abzuleitenden Vorgehensmodell zugrunde gelegt werden
kann. Im ersten Schritt wird daher ein synoptischer Vergleich vorgenommen, um
danach wichtige allgemeine Aspekte für Vorgehensmodelle sowie relevante Aspekte
aus dem Anwendungskontext betrachten zu können.
139
Der nachfolgende Vergleich orientiert sich in der Vorgehensweise an den Arbeiten
von Chroust516, Lanninger517 und Saha518. In diesen Arbeiten wird der Ablauf einzelner Vorgehensmodelle in der Softwareentwicklung (Chroust, Saha) bzw. zur Systemauswahl und –entwicklung (Lanninger) im Zeitverlauf dargestellt und verglichen.
Abbildung 44 zeigt aus Gründen der Übersicht nun einen Ausschnitt der untersuchten Modelle519. Diese wurden ausgewählt, um einen Überblick über die Vielfalt der
unterschiedlichen Ansätze zu vermitteln. Ferner wurden diese bereits in Kapitel 5.3
besprochen.
Abbildung 44: Vergleich ausgewählter Vorgehensmodelle (eigene Darstellung)
516
Vgl. Chroust (1992)
517
Vgl. Lanninger (2009, S. 151)
518
Vgl. Saha (2004)
519
Die vollständige Analyse beinhaltet darüber hinaus folgende Vorgehensmodelle: klassische
Vorgehensmodelle der Software-Entwicklung in Chroust (1992) (8 unterschiedliche Modelle), GERA
Lifecycle und TOGAF ADM in Saha (2004), Vorgehensmodelle zur Systemauswahl und -entwicklung
in Lanninger (2009, S. 151) (7 unterschiedliche Modelle), Spiralmodell Boehm (1988), Prototypingorientiertes Prozessmodell in Pomberger und Pree (2004, S. 26–32) und Pomberger und Blaschek
(1996, S. 24–26), Business Engineering Phasen in Österle (1995, S. 23) und IS-Projekt-Phasen von
Österle et al. (1992, S. 285), V-Model XT (URL: www.v-modell.iabg.de [1.12.2012]), Phasenkonzept
zur Individualsoftwareentwicklung (Balzert) und Phasenkonzept zur Auswahl und Einführung von
Standardsoftware in Mertens et al. (2000), Phasenmodell der Systementwicklung in Schwarze (2000,
S. 166).
140
Die Abbildung zeigt, dass die Modelle trotz ihrer verschiedenartigen Darstellungsformen auf synoptischer Ebene gut vergleichbar sind und einem gemeinsamen Ablauf
folgen. Die Grundlage aller betrachteten Vorgehensmodelle bildet die Unterteilung
eines Projektes in einzelne, logisch aufeinander folgende Schritte, die in den Modellen zu Aktivitätenblöcken oder Phasen zusammengefasst werden. Üblich ist eine
Gliederung in vier bis acht Phasen, durch die der Entwicklungsprozess in planbare
und kontrollierbare Einheiten zerlegt wird. Dies dient zur Komplexitätsreduktion und
zur Erleichterung des Projektcontrollings520. Die Zusammenfassung einzelner Aktivitäten in Phasen ist zwar unterschiedlich, jedoch folgen die Vorgehensweisen einem
Ablauf von „Orientierung“, „Analyse“, „Design“, „Realisierung“ und „Betrieb“.
Die unterschiedliche Anzahl an Phasen in den Modellen wird durch die Weite der
Sichtweise und damit verbundenen Aufteilung der Aktivitätenblöcke begründet. In der
weitgefassten Definition umfasst die Software- und Systementwicklung einerseits
auch die vorgelagerte Systemplanungsphase einschließlich der Durchführungsentscheidung und andererseits die Phase der Evaluierung und Weiterentwicklung der
Software bzw. des Systems nach dem produktiven Rollout521. Folgende Phasen
konnten identifiziert werden:

Orientierung: Die erste Phase dient einigen Modellen zur strategischen Planung des Projektes. Das Projekt bzw. Teilprojekte wird/werden begründet und
zu das entwickelnde System wird auf Machbarkeit hin geprüft. Am Ende der
Initialisierungs- und Orientierungsphase steht die Entscheidung, das Gesamtprojekt fortzusetzen oder abzubrechen („Go/No-Go Entscheidung“).

Analyse: Eine Analysephase findet sich in allen Modellen. Einige unterteilen
diese zusätzlich in eine Vor- und Feinstudie, Grob- und Feinanalyse, oder Istund Sollanalyse. Die Wichtigkeit dieser Phase wird beispielsweise im ISMVorgehensmodell hervorgehoben, da dadurch eine Überbetonung von technischen Komponenten zugunsten von Prozessen, Personen und Arbeitsweisen
verhindert wird.

Design: In den meisten Modellen findet sich eine Trennung zwischen Analyse
und Design. In der Design-Phase soll beschrieben werden, wie das zu entwickelnde System umgesetzt werden soll.

Realisierung: Alle Vorgehensmodelle weisen eine Phase zur Realisierung
auf. In dieser Phase wird das System (meist in mehreren Sub-Phasen) technisch umgesetzt. Die Implementierung kann eine Eigenentwicklung, oder den
Zukauf von Standardsoftware bzw. –systemen nach sich ziehen und Inhouse
520
521
Vgl. Eicker (2012b)
141
oder von Drittanbietern durchgeführt werden. Am Ende der Realisierung steht
der produktive Einsatz („Rollout“).

Betrieb: Nach dem Rollout wird das System produktiv eingesetzt. Einige Modelle enden nach der Installierung und Einführung des Systems. Änderungen
von internen Abläufen oder Anforderungen von externen Partnern benötigen
allerdings eine Wartung des produktiven Systems. Evaluierung, Monitoring,
Optimierung und kontinuierliche Weiterentwicklung werden daher in einigen
Modellen als Teil des Vorgehens angeführt.
Neben den Aufgaben in den Phasen, findet sich auch die Wichtigkeit von phasenübergreifenden Tätigkeiten explizit in der Darstellung einiger Vorgehensmodelle.
Wert wird vor allem auf eine durchgängige Dokumentation, Qualitätssicherung, Test,
Projektmanagement (bzw. Multiprojektmanagement) sowie Change Management als
integrierter Bestandteil des Vorgehens gelegt. Keen merkte bereits Anfang der
1980er Jahre, dass Veränderungsprojekte auf einer inkrementellen Herangehensweise aufbauen sollten522. Es ist außerdem allgemein anerkannt, dass Change
Management wichtig für den Erfolg von Projekten ist523, vor allem dann, wenn überund zwischenbetriebliche Informationssysteme integriert werden524. Auch die Kommunikation als zentraler Erfolgsfaktor im Zuge des Change Management soll hervorgehoben werden. Sie begleitet das Projekt in allen Phasen und stellt immer wieder
den Kontakt zwischen Projekt und Betroffenen her525. Change Management dient
also vor allem dazu, die sogenannten „weichen“ Faktoren („Soft Facts“) zu adressieren. Rahmenwerke wie „DICE (Duration, Integrity, Commitment, Effort)“ helfen dabei
Change Initiativen zu bewerten und zu überwachen526. Allerdings fehlen darin Handlungsanleitungen für einen erfolgreichen Wandel. Ein Vorgehensmodell soll diese
Handlungsanleitungen geben und dem Widerstand von Organisationen, Gruppen
oder einzelnen Personen, die die Veränderung als negativ empfinden, entgegenwirken.
5.5 Anforderungen an das Vorgehensmodell
Im folgenden Abschnitt werden die identifizierten Anforderungen an das Vorgehensmodell, das im Kontext betrieblicher Integrationen eingesetzt werden soll, zusammengefasst. Die Anforderungen ergeben sich einerseits aus allgemeinen Aspekten
522
Vgl. Keen (1981, S. 24)
523
Vgl. Ibbs et al. (2001, S. 164)
524
Vgl. Sutanto et al. (2008, S. 135)
525
Vgl. Stolzenberg und Heberle (2006, S. 62)
526
Vgl. Sirkin et al. (2005, S. 114)
142
von Vorgehensmodellen aus der Literatur (aus dem gegenständlichen Kapitel).
Andererseits werden spezielle Anforderungen diskutiert, welche aufgrund der Einführung von Integrationstechnologien zur Kommunikation, Koordination, Kooperation
und Kollaboration wichtig sind (aus den Kapiteln 2 und 3). Tabelle 10 liefert eine
Übersicht der Anforderungen, welche vom Vorgehensmodell zu unterstützen sind.
Die Codierung der Spalte „Nr.“ teilt die Anforderungen in allgemeine Anforderungen
von Vorgehensmodellen („AllgA“) und spezielle Anforderungen aus dem Forschungsund Anwendungskontext („SpezA“) ein. Die Spalte „Quelle(n)“ dient der nachvollziehbaren Ableitung jeweiligen Anforderung aus den vorangegangenen Kapiteln.
Tabelle 10: Anforderungen an das Vorgehensmodell
Nr.
Beschreibung
Quelle(n)
AllgA-1
Eine Gliederung der Gesamtaufgabe in einzelne
Schritte (dh. Aktivitäten) ist vorzunehmen.
AllgA-2
Einzelne Aktivitäten sind in logisch aufeinanderfolgende
Phasen zu gruppieren, die den gesamten Integrationsprozess repräsentieren.
Jede Phase hat, neben den auszuführenden Aktivitäten,
einzelne anwendbare Methoden und Werkzeuge sowie
eine Zuordnung zu Rollen zu beinhalten.
Die Ergebnisse von Aktivitäten in jeder Phase sind zu
definieren. Der Output eines Ergebnisses kann auch
Input für eine nachfolgende Aktivität sein.
Die Einführung von betrieblicher Integration ist strategisch zu planen und auszurichten.
Definition Vorgehensmodell
(Kapitel 5.1); Synoptischer
Vergleich (Kapitel 5.4)
(Kapitel 5.1); Synoptischer
Vergleich (Kapitel 5.4)
(Kapitel 5.1 bzw. Abbildung
32)
(Kapitel 5.1 bzw. Abbildung
32)
Vergleich Ansätze und
Rahmenwerke (Kapitel 3.4)
bzw. Ansätze in den Kapiteln
3.3.1, 3.3.2 und 3.3.6; Studie
Kapitel 4.2.2
Herleitung in Kapitel 3.2
AllgA-3
AllgA-4
SpezA-1
SpezA-2
SpezA-3
SpezA-4
SpezA-5
SpezA-6
Durchführung einer ganzheitlichen Analyse unter
Berücksichtigung der Integrationsdimensionen Technologie, Organisation (inner-, über- und zwischenbetrieblich) und betriebliches Umfeld sind zu adressieren.
Auf eine partizipative Vorgehensweise in allen Phasen
ist zu achten.
Die vielfältigen Möglichkeiten und Konzepte der betrieblichen Integration auf unterschiedlichen Integrationsebenen sind zu unterstützen.
Einer evolutionären Entwicklung mittels Prototyping ist
Rechnung zu tragen.
Die Anwendbarkeit des Modells in der Unternehmenspraxis ist zu sicherzustellen.
Globale Zielsetzung (Kapitel
2.1)
Herleitung in Kapitel 3.4
Diskussion in Kapitel 5.2 bzw.
Vorgehensmodelle in den
Kapiteln 5.3.4, 5.3.7, 0.
Globale Zielsetzung (Kapitel
2.1)
Die allgemeinen Anforderungen wurden aus der Definition und dem Vergleich der
Charakteristika von Vorgehensmodellen abgeleitet. Dabei sind die Aspekte der
Metastruktur für Vorgehensmodelle nach der Gesellschaft für Informatik (vgl. Abbil-
143
dung 32) zu berücksichtigen. Dies beinhaltet zunächst eine Gliederung der Gesamtaufgabe in einzelne Schritte, dh. einzelne auszuführende Aktivitäten („AllgA-1“).
Diese Aktivitäten sind in mehrere, logisch aufeinanderfolgende Phasen zu gruppieren („AllgA-2“), da Phasenmodelle allgemein anerkannt und in der Praxis am häufigsten anzutreffen sind. Die Phasen sollen den gesamten Integrationsprozess repräsentieren und einem gemeinsamen, in gängigen Vorgehensmodellen aus der Literatur
identifizierten, Ablauf folgen. Jede Phase soll, neben den auszuführenden Aktivitäten, einzelne anwendbare Methoden und Werkzeuge sowie eine Zuordnung zu
Rollen beinhalten („AllgA-3“). Die Verwendung von praxiserprobten Methoden und
Werkzeugen ist sicherzustellen. Darüber hinaus sollen die Ergebnisse in jeder
Phase definiert werden („AllgA-4“). Die Ergebnisse werden von den Aktivitäten produziert und bilden den Output der Tätigkeiten von Aktivitäten. Der Output eines
Ergebnisses kann auch Input für eine nachfolgende Aktivität sein.
Spezielle Anforderungen ergeben sich aus dem Forschungs- und Anwendungskontext des Vorgehensmodells. Wie bereits im Vergleich von Ansätzen und Rahmenwerken in den Grundlagen der Arbeit dargelegt, ist die Einführung von betrieblicher
Integration strategisch zu planen und auszurichten, dh. die Strategieorientierung ist
im Vorgehensmodell zu unterstützen („SpezA-1“). Im Prozess sind dabei Aktivitäten
und Maßnahmen im Kontext aller Integrationsdimensionen (Technologie, Organisation und Umfeld) zu adressieren („SpezA-2“). Dies bedingt die Durchführung einer
möglichst ganzheitlichen Analyse von wissensintensiven Prozessen im Unternehmen, um potentielle (zukünftige) zu unterstützende Prozesse und Arbeitsweisen zu
identifizieren und adressieren zu können. Kritisiert werden Phasenmodelle neben
fehlenden Aspekten zur Verbesserung organisatorischer Abläufe auch häufig aufgrund der nicht expliziten Behandlung des Akzeptanzproblems527. Da unterschiedliche interne und externe Personengruppen („Stakeholder“) im Veränderungsprozess
involviert sind, ist daher vor allem auf eine partizipative Vorgehensweise in allen
Phasen (dh. von Beginn an) zu achten („SpezA-3“). Alle relevanten Stakeholder sind
zu identifizieren und geeignet in den Prozess einzubinden, um eine positive Unternehmenskultur („Bottom-Up Kultur“) und Akzeptanz herstellen zu können. Bei der
Realisierung der Integrationslösung sind die vielfältigen Möglichkeiten und Konzepte
der betrieblichen Integration auf unterschiedlichen Integrationsebenen zu unterstützen („SpezA-4“). Dies beinhaltet die Integration auf Ebene der Daten und auf Ebene
der betrieblichen Informationssysteme, den Einsatz von Middleware zur Integration,
die Integration auf sozialer Ebene sowie die Integration auf Ebene der Prozesse.
Darüber hinaus soll einer evolutionären Entwicklung Rechnung getragen werden
(„SpezA-5“). Eine evolutionäre Vorgehensweise mittels Prototyping wird vor allem bei
der Einführung von Konzepten und Technologien auf sozialer Ebene und Prozess-
527
Vgl. Koch (2008, S. 63)
144
ebene als wichtig angesehen, da dieses Vorgehen rasch vorzeigbare Ergebnisse
liefert („Quick Wins“) bei gleichzeitiger Beachtung einer ganzheitlichen Analyse. Zur
Vermeidung von Doppelarbeiten sind die zu erzielende „Quick Wins“ in bestehende
Prozesse und Arbeitsweisen zu verankern. Wie eingangs erläutert, basiert der gewählte Forschungsansatz auf theoretisch fundierten und in der Praxis anwendbaren
Erkenntnissen und Methoden. Die Relevanz und Anwendbarkeit des Modells in der
Unternehmenspraxis ist daher sicherzustellen („SpezA-6“). Hierzu ist anzumerken,
dass durch ein durchgängiges, methodisches Vorgehen der Umgang mit „weichen“
Faktoren, also Restriktion auf politischer und persönlicher Ebene, zwar nicht gelöst,
aber methodisch unterstützt werden können. Diese Unterstützung ersetzt allerdings
den persönlichen Einsatz des Projektteams und des Top Managements eines Unternehmens nicht528. Das Vorgehensmodell soll die dafür benötigten Kompetenzen im
Zusammenhang mit der Wandlungsfähigkeit, Prozessorientierung und Benutzerzentriertheit durch geeignete Methoden adressieren. Das Vorgehensmodell soll dabei
auch explizit die Förderung des Engagements und der resultierenden Notwendigkeit
zur Bereitschaft zum Wandel berücksichtigen. Phasenübergreifende Tätigkeiten zum
Qualitätsmanagement, Projektmanagement und vor allem ein kontinuierliches Change Management sind für den Erfolg des Projekts wichtig. Um den praxistauglichen
Ablauf und die Verwendung von praxiserprobten Methoden und Werkzeugen zu
gewährleisten, sind daher Pilotprojekte durchzuführen und Erkenntnisse daraus in
einem konsolidierten Vorgehensmodell aufzunehmen.
5.6 Zusammenfassung
Die gegenständliche Arbeit beschäftigt sich mit der Erstellung eines Vorgehensmodells für die betriebliche Integration („Modell für Etwas“) und lässt sich demzufolge
dem konstruktionsorientierten Ansatz zuordnen. Die durchgeführte Literaturrecherche
machte deutlich, dass Vorgehensmodelle aufgrund der Komplexität von Integrationsprojekten sinnvoll und auch notwendig sind. Auch Biehl unterstreicht die Notwendigkeit einer sorgfältigen Planung und Durchführung mit folgender Aussage:
“Planning and implementing a system must be done with a sense of urgency, but not at
the cost of proper planning.”529
Ein Vorgehensmodell ist nun ein Grundgerüst für ein strukturiertes Vorgehen zur
Lösung eines Problems. Im speziellen wird unter dem Vorgehensmodell der als
Modell abgebildeter, standardisierter Prozess zur zielgerichteten, partizipativen
Integration verstanden, der im Zuge der Projektplanung an die jeweilige Projektum-
528
529
Biehl (2007, S. 58)
145
gebung im Unternehmen angepasst wird. Das Vorgehensmodell ist in logische Phasen zu gliedern und hat neben der Beschreibung der auszuführenden Aktivitäten
(bzw. Tätigkeiten) und Ergebnissen, die im speziellen anzuwendenden Methoden
und Werkzeuge sowie ein Rollenmodell zu beinhalten.
Die mittels Literaturrecherche identifizierten Vorgehensmodelle zur Software- und
Systementwicklung wurden einem Vergleich unterzogen und damit die wissenschaftliche Fragestellung (FS3) beantwortet. Es konnte gezeigt werden, dass sich gängige
Vorgehensmodelle gut vergleichen lassen. Obwohl Anzahl der Phasen und deren
Bezeichnungen variieren, konnte ein Grundmuster aus „Orientierung“, „Analyse“,
„Design“, „Realisierung“ und „Betrieb“ erkannt werden. Diese allgemein verwendeten
Phasen sollen in der Folge in einem angepassten Vorgehensmodell für den Kontext
betrieblicher Integration mit konkreten Aktivitäten und Methoden hinterlegt werden.
Zuletzt wurden wichtige Anforderungen an das zu entwickelnde Vorgehensmodell
abgeleitet. Die Anforderungen sind dabei als Mindestanforderungen zu sehen; als
Anforderungen, die in jedem Fall zu unterstützen sind. Es wird angenommen, dass
die Besonderheiten betrieblicher Integration innerhalb der einzelnen Phasen, dh. in
den phasenspezifischen Methoden, Aktivitäten und Ergebnissen, adressiert werden
müssen. Sollten sich wichtige Aspekte aus Sicht der Praxis oder Wissenschaft zu
einem späteren Zeitpunkt der Forschung ergeben (z.B. bei der Durchführung von
Fallstudien oder Pilotprojekten, oder bei der Dissemination von Teilergebnissen),
sind diese im Zuge der Konsolidierung des Vorgehensmodells geeignet zu berücksichtigen.
146
Fallstudien zur betrieblichen Integration
6 Fallstudien zur betrieblichen Integration
Das gegenständliche Kapitel wird drei Beispiele betrieblicher Integrationslösungen
darstellen. Die Dokumentation und der daran anschließende Vergleich der als Mehrfach-Fallstudie erhobenen Beispiele beantworten die wissenschaftliche Fragestellung
(FS4): Wie lassen sich in der Praxis bereits erfolgreich durchgeführte Projekte zur
betrieblichen Integration systematisiert erheben, charakterisieren und in den Kontext
dieser Arbeit einordnen?530
Wie in Abbildung 45 ersichtlich, beginnt das Kapitel mit der Darstellung der Methodik
zur Erhebung sowie eines Überblicks über die erhobenen Fallstudien (Kapitel 6.1).
Die darauffolgenden Kapitel behandeln die drei Fallbeispiele im Detail (Kapitel 6.2,
6.3 und 6.4). Darin werden zunächst die von der Integration betroffenen Unternehmen vorgestellt, danach wird auf die Vorgehensweise bei der Integration eingegangen und schließlich wird die jeweils entwickelte Integrationslösung diskutiert. Kapitel
6.5 enthält den Fallstudienvergleich und eine erste Modellbildung findet statt. Die
zentralen Ergebnisse aus den Fallstudien werden in Kapitel 6.6 zusammengefasst.
530
147
6.1 Methodik und Überblick
Zur konsistenten Erstellung vergleichbarer Fälle wurden die Ergebnisse aller Fallstudien nach der Methode zur Erhebung von Business Engineering Case Studies
(PROMET BECS)531 durchgeführt. Das Konzept der replizierbaren MehrfachFallstudie sieht dabei eine Triangulation von Daten, Methoden, Perspektiven und
Forscher vor, um die Qualität der Fallstudie zu verbessern532. Dies wurde in der
Arbeit durch folgende Maßnahmen berücksichtigt: Die Methoden-Triangulation umfasste Experteninterviews, Beobachtung und Dokumentenanalyse. Die DatenTriangulation wurde durch Verwendung von mehreren Quellen für die zu erhebenden
Fakten sichergestellt. Die Fallstudien erheben das Forschungsphänomen der betrieblichen Integration aus wirtschaftlichen, prozessorientierten, technischen sowie organisatorischen Gesichtspunkten (Perspektiven-Triangulation). Die Triangulation der
Forscher wurde insofern beachtet, dass bei der Durchführung der Fallstudie immer
mehrere Personen in den Rollen Fallstudien-Ersteller, Co-Interviewer und/oder
Reviewer beteiligt waren.
Um die Strukturen, Abläufe und die hinter einer betrieblichen Integration liegende
technische Infrastruktur verstehen zu können, ist es notwendig, diese in ihrer natürlichen Umgebung zu studieren533. Die Fallstudien sind deshalb jeweils aus Sicht des
zu integrierenden Unternehmens sowie eines Integrationspartners erhoben worden.
Sie behandeln die Auslagerung von Kerngeschäftsprozessen eines KMU im Handel
(Fallstudie 1, siehe Kapitel 6.2), die Einführung einer elektronischen Rechnungslegung in einem KMU der Schuhmacher-Branche auf einer Software-as-a-Service
(SaaS) Basis (Fallstudie 2, siehe Kapitel 6.3) und die Verwendung von Software als
Middleware zur B2B-Integration eines auf Malerbedarf spezialisierten KMU zur
elektronischen Übermittlung von EDI-basierten Standardnachrichten an dessen
Großkunden (Fallstudie 3, siehe Kapitel 6.4). Tabelle 11 fasst diese Eckdaten zusammen.
Tabelle 11: Eckdaten der Fallstudien
Beteiligte Unternehmen
Erstkontakt
Erhebungszeitraum
Fallstudie 1
Fallstudie 2
Fallstudie 3
Büroprofi GmbH
ABC GmbH
Büroprofi GmbH
(CEO)
01/2008 – 09/2008
GRZ IT GmbH
Schütze Schuhe
GRZ IT GmbH
(Produktmanager)
03/2008 – 09/2008
Schuller GmbH
Xynamics GmbH
Xynamics GmbH
(CEO)
09/2008 – 04/2009
531
Vgl. Senger und Österle (2004)
532
Vgl. Yin (2003, S. 98–99); Radeke (2010, S. 8)
533
148
Fallstudie 1
Durchführungszeitraum 01/2004 – 12/2004
der Integration
Anzahl persönliche
1 Kick-Off Büroprofi,
Treffen
1 Experteninterview
Haupt-Ansprechpartner
Interviewpartner seitens Unternehmen
Firmenbesuche
Fallstudien-Ersteller
Co-Interviewer
Reviewer
Büroprofi und ABC
(gemeinsam),
1 Experteninterview
Büroprofi Technik
CEO Büroprofi
4 Personen
(CEO Büroprofi, Leiter
IT Büroprofi, Leiter
CIPS Büroprofi, ABC
Mitarbeiter Vertrieb)
2
(Büroprofi Technik &
Serverinfrastruktur,
Büroprofi Waren &
Logistik)
Dietmar Nedbal (FH
Steyr)
Andreas Auinger
Nedbal (FH Steyr)
Beteiligte Unternehmen (CEO Büroprofi,
ABC Mitarbeiter
Vertrieb), FH Steyr
(Gerald Petz und
Gerold Wagner)
Fallstudie 2
Fallstudie 3
03/2007 – 05/2007
04/2008 – 12/2008
1 Kick-Off GRZ,
1 Experteninterview
GRZ,
1 Experteninterview
CEO Schütze
Schuhe
GRZ IT Produktmanager flexdoc
2 Personen
(GRZ IT Produktmanager flexdoc, CEO
Schütze Schuhe)
1 Kick-Off Xynamics,
1 Experteninterview
Xynamics und
Schuller (gemeinsam)
2
(GRZ IT, Schütze
Schuhe Firmenbesuch)
1
(Schuller Firmenbesuch)
Dietmar Nedbal (FH
Steyr)
Andreas Auinger
Nedbal (FH Steyr)
Beteiligte Unternehmen (GRZ IT Produktmanager flexdoc,
CEO Schütze
Schuhe), FH Steyr
(Gerald Petz und
Gerold Wagner)
Dietmar Nedbal (FH
Steyr)
Andreas Auinger
Nedbal (FH Steyr)
Beteiligte Unternehmen (Filialleiter
Schuller, CEO
Xynamics), FH Steyr
(Gerald Petz und
Gerold Wagner)
CEO Xynamics
2 Personen
(Filialleiter Schuller,
CEO Xynamics)
Der Ablauf bei der Erhebung der Fallstudien verlief analog zu der von Senger und
Österle vorgeschlagenen Vorgehensweise (PROMET BECS) in den Schritten Unternehmen auswählen, Interview durchführen und Forschungsfall erstellen534.
6.1.1 Unternehmen für Fallstudie auswählen
Die Unternehmen für die Fallstudien wurden nicht zufällig ausgewählt, sondern auf
Grund ihrer Erfahrungen in der betrieblichen Integration. Jedes Unternehmen hat in
der Vergangenheit Integrationsprojekte auf unterschiedlichen Ebenen erfolgreich
durchgeführt. Ein wichtiges Kriterium für die Auswahl war der Haupt-Ansprechpartner
in den Unternehmen. Dieser sollte durch eine mehrjährige Firmenzugehörigkeit über
ausreichende praktische Erfahrung verfügen. Er sollte auch in der Lage sein, ein
534
Vgl. Senger und Österle (2004, S. 26–29)
149
Partnerunternehmen für die Darstellung der Integrationslösung zu benennen, um
beide Sichtweisen der Partnerschaft erheben zu können. Zudem sollte er Hilfestellung bei der Auswahl von Interviewpartner geben können und Zugang zu etwaig
benötigte Unternehmensinformationen und Dokumenten haben. Zuletzt war es auch
wichtig, dass die Unternehmen einen freien Zugang zu den benötigten Informationen
gestatten und eine objektive Analyse dieser zulassen. Alle ausgewählten Unternehmen erfüllten diese Kriterien.
Der Erstkontakt mit den Unternehmen erfolgte telefonisch. Es wurden die Ziele und
der Nutzen der Fallstudie geklärt und zu einem persönlichen Treffen eingeladen.
Beim folgenden Kick-Off Termin wurde die Fallstudie erläutert und das weitere Vorgehen besprochen. Gemeinsam wurde ein Partnerunternehmen für die Beschreibung
der Integrationslösung identifiziert und mögliche Ansprech- und Interviewpartner
fixiert. Bei der Auswahl der Personen war es wichtig, dass sie sowohl die geschäftliche Sicht als auch die technische Seite der Integration abgedeckt war535.
6.1.2 Experteninterviews durchführen
Yin unterstreicht das semi-strukturierte Interview als eine der wichtigsten Informationsquellen für die Erstellung einer Fallstudie536. Zur Vorbereitung auf die Interviews
wurde deshalb ein Leitfaden erstellt. Dieser wurde mit einer Beschreibung des Ablaufs den Gesprächsteilnehmern vorab per E-Mail übermittelt. Der Interviewleitfaden
beinhaltet ein leeres Fallstudienraster mit kontextbezogenen Fragen. Allgemeine
Informationen zu den Unternehmen (Unternehmensgröße, Umsatz, Geschäftsfelder,
etc.) wurden vorab über deren Internetauftritt recherchiert und zu Beginn des Interviews auf Korrektheit überprüft537.
Die Experteninterviews wurden von Fallstudien-Ersteller und Co-Interviewer gemeinsam durchgeführt. Dies war zur Wahrung der Qualitätsziele Objektivität, Vollständigkeit und zum Review der Dokumentation erforderlich. Ein starres Festhalten der
Leitfadenstruktur wurde unterlassen. Fragen wurden von beiden Interviewern gestellt
und handschriftlich dokumentiert. Auf die Aufzeichnung des Gesprächs wurde ebenfalls verzichtet, da dadurch die Gesprächsatmosphäre negativ beeinträchtigt werden
kann und da aufgrund der exakten Wortwahl der Experten kein zusätzlicher Erkenntnisgewinn zu erwarten war538.
535
Vgl. Senger und Österle (2004, S. 26)
536
Vgl. Yin (2003, S. 89)
537
Der Leitfaden für die Experteninterviews befindet sich im Anhang (Anhang C: Struktur für Fallstudien mit Fragen für Interviews).
538
150
Im Zuge der Experteninterviews wurde in allen Fallstudien eine Firmenbesichtigung
durchgeführt539. Damit wurde der Forderung nach Methoden-Triangulation bei Fallstudien nachgekommen. Die relevanten Prozesse (wie Bestellung oder Warenlieferung) konnten mittels direkter Beobachtung im Feld und Befragung um zusätzliche
Fakten ergänzt werden und Fehler die etwa durch den Einfluss der Interviewer entstanden sein könnten, konnten dadurch entdeckt und korrigiert werden540.
6.1.3 Forschungsfall erstellen
Eine erste Version der Fallstudie wurde vom Fallstudien-Ersteller auf Basis beider
Mitschriften erstellt und vom Co-Interviewer auf Korrektheit, Vollständigkeit und
Konsistenz überprüft. Noch offene Fragen wurden entsprechend markiert. Für Fallstudie 1 war ein zusätzlicher Interviewtermin mit Ansprechpersonen aus der Technik
von Büroprofi erforderlich. Die anderen offenen Fragen konnten per E-Mail oder
telefonisch beantwortet werden. Dazu wurden auch zusätzliche Dokumente wie
Produktbeschreibungen, Präsentationen oder Marketingunterlagen von den Unternehmen angefordert und in die Fallstudie eingearbeitet.
Die Verwendung von mehreren Quellen für das gleiche Forschungsphänomen verbessert die Validität der Fakten erheblich und erhöht damit die Qualität der Fallstudie.
Yin spricht in diesem Zusammenhang von „echter“ Daten-Triangulation, dh. gleiche
Ereignisse und Fakten der Fallstudie wurden durch verschiedene Quellen belegt541.
Nach Einarbeitung aller Unterlagen und Überprüfung durch den Co-Interviewer
wurde die Fallstudie zum Review an beide beteiligten Unternehmen gesendet. Zur
Gewährleistung der Verständlichkeit wurden die Fallstudien in einer Expertenrunde
mit unbeteiligten Dritten besprochen. Das Feedback der Reviewer wurde in die
Fallstudien eingearbeitet und nochmals an die beteiligten Unternehmen für etwaige
letzte Korrekturen gesendet542.
6.2 Fallstudie 1: Betriebliche Integration durch Outsourcing von
Geschäftsprozessen (Büroprofi)
Diese Fallstudie aus der Papier-, Büroartikel- und Schreibwaren-Branche (PBSBranche) stellt einen umfassenden Ansatz zur Integration von Kerngeschäftsprozessen und Services entlang der Wertschöpfungskette dar. Die Fallstudie wird aus Sicht
539
Siehe Tabelle 11
540
Vgl. Lamnek (2005, S. 317)
541
Vgl. Yin (2003, S. 99)
542
151
der ABC GmbH, eines mit Büroprofi kooperierenden KMU, betrachtet. Die Fallstudie
ist auch in einer gekürzten Fassung als Beitrag in der Zeitschrift HMD erschienen543.
6.2.1 Unternehmensdarstellung der beteiligten Unternehmen
Die wesentlichen Akteure der Fallstudie sind die ABC GmbH544, ein kleines Unternehmen mit Geschäftstätigkeit rund um den Büroarbeitsplatz und die Büroprofi
GmbH, ein Dienstleistungsunternehmen der Papier-, Büroartikel- und SchreibwarenBranche (kurz: PBS-Branche). Büroprofi ist eine 100% Tochtergesellschaft von PBS
Holding AG und bietet seit 1991 KMUs auf Partnerbasis vollständig integrierte Prozesse in Verbindung mit modernen Logistikleistungen und Bestellmedien an. Mit über
100 Büroprofi-Partnern in Österreich und Deutschland hat sich diese Integrationslösung erfolgreich in der Praxis bewährt. Die verwendeten Strategien, Methoden und
Werkzeuge zum Aufbau und Betrieb der Integrationslösung sind weitgehend konsolidiert und repräsentativ.
Mit 15 Mitarbeitern in den Abteilungen Geschäftsführung, Buchhaltung, Marketing &
Vertrieb und Lager positioniert sich die ABC GmbH als Komplettanbieter rund um
den Büroarbeitsplatz mit den Geschäftsfeldern Büromöbel (von der Planung des
Arbeitsplatzes bis Montage der Möbel inkl. Accessoires) und Büroartikel des täglich
anfallenden Bürobedarfs. Das Kundenspektrum reicht von Industrie, Klein- und
Mittelbetrieben über freiberuflich Tätige bis zum öffentlichen Bereich. Der Büroartikelmarkt ist hart umkämpft und stagnierend, man ist als Anbieter leicht austauschbar
und die Kundenbindung ist schwierig. Im Allgemeinen ist die nationale wie auch
internationale Marktentwicklung im Papier-, Büro- und Schreibwarenmarkt durch
Konsolidierungstendenzen geprägt. Die Nachfrage nach den Produktgruppen in den
„westlichen“ Märkten stagniert. Auch für die kommenden Jahre wird am österreichischen Markt mit Zuwachsraten von max. 2 bis 3% pro Jahr gerechnet. Wachstumsmärkte sind vor allem im osteuropäischen Raum gegeben.
Die ABC GmbH verfügt über einen Internet Anschluss, hat allerdings keinen eigenen
Verantwortlichen für die IT. Die IT wird von einem externen EDVDienstleistungsbetrieb betrieben und von einem eigenen Mitarbeiter mit betreut. Das
Unternehmen setzt ein Warenwirtschaftssystem (WWS) für beide Geschäftsfelder
ein. Dabei handelt es sich um eine Individualentwicklung, die als unflexibel und
umständlich in der Handhabung angesehen wird. Das WWS wird auf einem InhouseServer betrieben. Zusätzlich verfügt das Unternehmen über einen eigenen Datenserver.
543
Vgl. Nedbal et al. (2012b)
544
Der Name wurde auf Wunsch des Unternehmens für die Fallstudie anonymisiert.
152
6.2.2 Vorgehensweise bei der Integration
Feststellen des Integrationsbedarfs. Der Auslöser des Integrationsbedarfs ist
primär externer Natur. Die Positionierung als Komplettanbieter am Markt ist aufgrund
des nicht mehr wirtschaftlich bedienbaren Geschäftsfeldes Büro- und Verbrauchsartikel sehr stark gefährdet. In den letzten Jahren hat sich eine Verschiebung der Geschäftsfelder von Büroartikel auf Büromöbel abgezeichnet. Eine Veränderung der
Kundenstruktur durch eine stärkere Ausrichtung auf KMUs ist beabsichtigt, da
dadurch das Risiko besser verteilt ist. Derzeit wird – im Gegensatz zu Büromöbel –
keine Umsatzsteigerung bei Büroartikeln, sondern eine Reduktion der Kosten bei
gleichbleibendem Umsatz angestrebt. Als Auslöser und Ziele für den Änderungsbedarf in diesem Geschäftsfeld werden vom KMU kürzere Lieferzeiten, zunehmender
Kostendruck, erhöhte Qualitätsanforderungen sowie geänderte Beschaffungsstrukturen gesehen. Die Geschäftsführung des KMU ist sich der Situation bewusst, verfügt
über keine schriftliche Integrationsstrategie oder E-Business Strategie, steht jedoch
unterschiedlicher Integrationsszenarien zur Verbesserung der Wettbewerbssituation
aufgeschlossen gegenüber.
Analyse des Integrationsbedarfs. Die ABC GmbH betrachtet zur Entscheidungsfindung die Ist-Situation unter organisatorischen, prozessorientierten und technischen Gesichtspunkten. Die Analyse, welche neben der Dokumentation organisatorischer Rahmenbedingungen nicht schriftlich verfasst wurde, ergibt, dass neben der
Schließung der Firma als Eskalationsvariante bzw. Auflassung des Geschäftsbereichs „Büroartikel“ eine B2B Integration mit einem Partnerunternehmen mögliche
weitere Schritte wären. Das Einstellen des Büroartikel-Segmentes könnte der Sanierung des Betriebes dienlich sein, bedeutet jedoch auch, die Positionierung als Komplettanbieter zu verlieren. Für viele Kunden ist dies zwar wahrscheinlich nicht maßgeblich, da es sich bei Büroartikeln um ein Verbrauchsgut und bei Büromöbel um ein
Investitionsgut und daher um unabhängige Entscheidungsprozesse handelt. Der
Image- und Vertrauensverlust bei bestehenden Kunden ist aber dennoch schwer
einschätzbar. Die zweite Variante wäre eine Anbindung über einen ausländischen
Partner. Die Fokussierung dieses Unternehmens auf den Großhandel und der fehlende Bezug zum österreichischen Markt (auch fehlende Niederlassungen) stellen
jedoch ein nicht zu unterschätzendes Risiko für das KMU dar. Als dritte Möglichkeit
bietet sich dem Unternehmen Büroprofi an. Büroprofi bietet aufgrund der Nähe zum
KMU lokale und persönliche Betreuung, zusätzliche Dienstleistungen und ist auf
KMUs ausgerichtet. Eine Anbindung an Büroprofi bedeutet eine Konzentration auf
die Kernkompetenzen Marketing und Vertrieb, welche durch die geografische Kundennähe und die persönlichen Kontakte zwar bestehen, jedoch auch den Verlust von
Freiheiten.
153
Design und Auswahl der Integrationslösung. Die verschiedenen Alternativen
führen zu einer Umsetzungsentscheidung zugunsten Büroprofi durch die Geschäftsführung der ABC GmbH. Die Kontaktaufnahme mit Büroprofi erfolgt telefonisch. Der
Geschäftsführer von Büroprofi ist erster Ansprechpartner und bleibt auch im gesamten Projektverlauf Ansprechperson und Koordinator. Auch für diese Phase werden
von der ABC GmbH keine schriftlichen Aufzeichnungen geführt. Es wird jedoch ein
Kooperationsvertrag zwischen der ABC GmbH und Büroprofi unterzeichnet.
Realisierung der Integrationslösung. Die Realisierung der Integrationslösung wird
methodisch und inhaltlich von Büroprofi geleitet. Die Anbindung an die Büroprofi
Systeme und Prozesse wird innerhalb eines Monats umgesetzt. Basis für die Auslagerung der Prozesse bildet die technische Integration, d.h. die Anbindung an die ITSysteme von Büroprofi. Das Bestell- und Warenwirtschaftssystem („CIPS“) ist vom
Büroprofi-Partner verpflichtend zu verwenden und steht als Inhouse-Lösung (bei der
ABC GmbH) oder als bei Büroprofi gehostete ASP-Lösung zur Verfügung. Die Kommunikation zwischen „CIPS“ und Büroprofi erfolgt bei der Inhouse-Lösung über WebEDI. Diese Umstellung erfordert die Einrichtung eines leistungsstärkeren Breitbandanschlusses seitens der ABC GmbH. Durch die Einbindung in die Marketingaktivitäten erhält die ABC GmbH einen persönlichen Webshop. Ein Newsletter an alle Kunden der ABC GmbH wird zweimal monatlich automatisiert elektronisch versandt. Des
Weiteren werden ein jährlicher Hauptkatalog, monatliche Mailings und Rechnungsbeileger von Büroprofi erstellt und auf postalischem Weg zugestellt. Der Prozess der
lagerlosen Lieferung wird von über 90% der Büroprofi-Partner aus Kostengründen
angenommen. Auch die ABC GmbH entscheidet sich aufgrund massiver Kosteneinsparungen durch das Auflassen des eigenen Lagers dafür. Nach erfolgter Systemanbindung erhält das Team der ABC GmbH eine 3-tägige Vor-Ort-Schulung in die ITSysteme.
Nach erfolgtem Rollout der IT-Lösung und Einführungsschulung erfolgt eine laufende
Begleitung durch Büroprofi bzgl. der Potenziale zur Prozessoptimierung. Für die
Bereiche Bestellung, Fakturierung, Kassa, Inventur und Finanzbuchhaltung stehen
Fachspezialisten seitens Büroprofi zur Beratung zur Seite. Die Erstintegration wird
bei der ABC GmbH nach 6 Monaten abgeschlossen.
Betrieb und kontinuierliche Verbesserung. Nach erfolgreicher Erstintegration
bietet Büroprofi Möglichkeiten zum Austausch von Know-How und Feedback mit
anderen Partnern und zum Einbringen von Verbesserungsvorschlägen seitens der
Partner (Stammtischrunde dreimal pro Jahr und Bundesland, Partnertreffen, Meetings, Schulungen, Trainings) bis hin zur persönlichen, quartalsweisen Unternehmensberatung vor Ort an. Mit diesem Feedback wird die Integrationslösung von
Büroprofi laufend erweitert und um neue Funktionen ergänzt.
154
6.2.3 Diskussion der Integrationslösung
Aus wirtschaftlichen und prozessorientierten Gründen sieht die Integrationslösung
vor, Doppelgleisigkeit in der Wertschöpfung (z.B. bezüglich Logistik, Lagerhaltung
und Marketing) durch Auslagerung maßgeblicher Prozesse der ABC GmbH an
Büroprofi zu vermeiden. Abbildung 46 zeigt die Wertschöpfung vom Hersteller bis
zum Endverbraucher. Beschaffung, Lagerung, Kommissionierung, Auslieferung und
Teile der Marketing-Aktivitäten werden von Büroprofi übernommen. Die ABC GmbH
konzentriert sich auf den Informationsfluss Richtung Endverbraucher und übernimmt
den Vertrieb sowie fallweise Direktmarketingaktivitäten, die sich aufgrund der Kundennähe ergeben. Die einhergehenden personellen Veränderungen und Umschulungen der Mitarbeiter im Lager, in der Kommissionierung und in der Auslieferung
werden von der ABC GmbH durchgeführt. Die ABC GmbH verfügt bereits aus der
Vergangenheit über gute, persönliche Kontakte zu den meisten ihrer Kunden, welche
im Zuge der einschneidenden Prozessveränderungen nun intensiviert und qualitativ
verbessert werden können. Wesentlicher Erfolgsfaktor nach der Integration ist die
Fähigkeit des Unternehmens, eine persönliche Kundenbindung herstellen zu können.
Abbildung 46: Wertschöpfung nach Outsourcing der Prozesse (eigene Darstellung)
Durch die Partnerschaft mit Büroprofi konnte die wirtschaftliche Situation der ABC
GmbH in mehreren Bereichen aufgrund folgender Faktoren verbessert werden:

Senkung der Personalkosten am Lager, da das Lagerpersonal für die Montage
von Büromöbeln übernommen wurde

Entfall der Kosten für die Lagerhaltung

Entfall der Kosten des Lieferfuhrparks

Reduktion der Marketing- und Katalogkosten
Die ABC GmbH rechnet mit durchschnittlich 8.500 Bestellungen pro Jahr im Geschäftsfeld Büroartikel, was sich im darauffolgenden Jahr nach der Integration nicht
merklich verändert hat. Demzufolge konnte eine Stagnation des Umsatzes herbeigeführt werden, was den intensivierten Vertriebs- und Marketingaktivitäten zugeschrieben wird. Die erheblichen Fixkosteneinsparungen führten zu einer Steigerung des
Gewinns von 5%. Die errechnete Amortisationsdauer auf der Basis des Belegvolumens zeigt, dass das investierte Kapital bereits nach dem ersten Monat über die
155
Erlöse wieder in das Unternehmen zurückgeflossen ist. Die ABC GmbH müsste bei
gleichen Kosten für Prozesse und Produkte die Anzahl von 26.250 Bestellungen an
Büroartikeln pro Jahr überschreiten, um wirtschaftlich erfolgreicher zu agieren als
über die gegenständliche Integration mit dem Büroprofi-Netzwerk.
Abbildung 47: Überblick über den Waren- und Informationsfluss der Integrationslösung der Fallstudie
„Büroprofi“ (eigene Darstellung)
Der qualitative Erfolg der Integration wird sowohl durch den in Abbildung 47 im
Überblick dargestellten durchgängig elektronischen Prozess von der Bestellung bis
zur Lieferung („Informationsfluss“) als auch durch zusätzliche Möglichkeiten der
Warenlieferung („Warenfluss“)545 mit erheblichen Prozessverbesserungen gegenüber
der ursprünglichen Abwicklung begründet. Der Endverbraucher bestellt im Webshop
oder bei der ABC GmbH auf klassischem Wege über Telefon, E-Mail oder Fax. Der
Auftrag landet automatisch im Bestellsystem „CIPS“ und die ABC GmbH wird davon
per E-Mail informiert. Die Bestellung kann im Bestellsystem bearbeitet, abgelehnt
und/oder freigegeben werden. Nach Freigabe der Bestellung wird automatisch ein
Auftrag generiert, der im IT-System von Büroprofi intern an den „TRADER“ geleitet
545
In der Literatur findet man auch eine Trennung in Warenfluss in eine Richtung, Zahlungen in die
andere Richtung und Informationen in beide Richtungen (Vgl. Premkumar (2000, S. 58)). Eine explizite Darstellung des Zahlungsflusses würde demnach auch Banken und Kreditinstitute mit einschließen.
Premkumar merkt an, dass Zahlungsflüsse auch als Teil des Informationsflusses verstanden werden
können, weshalb auf diese explizite Trennung verzichtet wurde. Diese Trennung ist auch für das
Verständnis der Integrationslösung nicht relevant und demnach auch nicht förderlich.
156
wird. Der „TRADER“ dient zur zentralen Verwaltung der Artikelstammdaten, des
Einkaufs und des Sortiments. Die zweite Kernkomponente, die „ISA“, wickelt die
gesamte Logistik und Kommissionierung des Händlernetzwerkes ab. Zu deren
Hauptaufgaben zählen die Erstellung der elektronischen Ladelisten für Spediteure,
die Übernahme der elektronischen Faktura von Herstellern und Spediteuren sowie
„Track & Trace“-Paketverfolgung. Die Ware wird bei lagerloser Lieferung von Büroprofi frachtoptimiert an den Endverbraucher versandt. Dabei sind insgesamt 10
Mitarbeiter von verschiedenen Spediteuren am Warenausgang von Büroprofi vor Ort.
Zusätzlich besteht bei Bestellungen von nur einem Hersteller die Möglichkeit der
Direktlieferung der Waren vom Hersteller an den Endverbraucher oder an die ABC
GmbH. Auf diese Weise werden ein zusätzlicher Einkaufsvorteil lukriert und die
Logistikkosten verringert. Büroprofi bezeichnet diese Art der Lieferung als „Computer
Aided Order System (kurz: CAOS) Lieferung“.
Durch die im Anwendungsszenario dargestellte betriebliche Integration entstehen
strategische Wertschöpfungsnetzwerke, die quantitative und qualitative Vorteile für
alle Netzwerk-Partner bringen. Die elektronische Anbindung aller Partner in der
Wertschöpfung macht ein 24 Stunden Lieferservice für über 15.000 Büroartikel im
Standardsortiment möglich. Damit verbunden ist auch eine erhebliche Steigerung der
Qualität durch die Verwendung von einheitlichen Nummernsystemen für Artikel,
Lieferanten und Kunden, Plausibilitätskontrollen bei der Kommissionierung und
Ausschaltung fehlerhafter Eingaben durch durchgehend elektronische Prozesse.
Dies hatte für die ABC GmbH eine Senkung der prozessbedingten Retouren in
hohem Ausmaß zur Folge.
6.3 Fallstudie 2: Elektronische Rechnungslegung (GRZ)
In dieser Fallstudie wird die Umsetzung einer elektronischen Rechnungslegung
behandelt. Dadurch konnte ein vollständig medienbruchfreier Fakturierungsprozess
erzielt werden, was erhebliche Einsparungen in Ressourcen, Zeit und Kosten zur
Folge hatte.
Die Schütze-Schuhe GmbH & Co. KG, ein KMU der Schuhmacher-Branche, hat
sich auf das Geschäftsfeld Sicherheitsschuhe für Gewerbe, Industrie, Bau, Baunebengewerbe, Behörden, Post/Bahn, Rettungsorganisationen und Polizei spezialisiert. Schütze-Schuhe ist ein Familienbetrieb mit 24 Mitarbeitern, Geschäftsführer
(CEO) ist Hr. Thomas Schützeneder. Das Unternehmen ist untergliedert die Abteilungen Produktion (12 Personen), Vertrieb (inkl. Fertigwarenlager, Versand, Fakturierung mit 7 Mitarbeitern) und Verwaltung (inkl. Buchhaltung und Geschäftsführung, 5
Personen)
157
Die gesamte Informationstechnologie wird durch einen nahegelegenen EDV Komplettanbieter für KMUs betreut. Dieser Dienstleister vertreibt und betreut auch das
von Schütze-Schuhe eingesetzte ERP-System „Winline“, das eine Individuallösung
mit Microsoft Access im Jahr 2006 abgelöst hat.
Anfang 2007 ist das Unternehmen nach dem Ausscheiden der für den Druck, Kuvertierung und Versand von Ausgangsrechnungen verantwortlichen Halbtagskraft entschlossen, keine zusätzlichen Personalressourcen mehr an diese Aufgabe zu binden. Auf Basis einer fundierten Entscheidungsfindung wird eine elektronische Rechnungslegung mittels „flexdoc“ angestrebt. Mit „flexdoc“ bietet das GRZ IT Center Linz
ein steuerrechtlich und revisionstechnisch zertifiziertes elektronisches DokumentenManagement für Angebote, Bestellungen, Auftragsbestätigungen, Lieferscheine,
Eingangs- und Ausgangs-Rechnungen, Gutschriften und Mahnungen.
Feststellen des Integrationsbedarfs. Der Auslöser des Integrationsbedarfs ist vor
allem innerbetrieblicher Natur. Nach dem Ausscheiden der für die Rechnungslegung
zuständigen Halbtagskraft aus dem Unternehmen gilt es, Personalressourcen und
Zeit zu optimieren. Zusätzlich kommt hinzu, dass der örtliche Postbeamte die Briefe
aufgrund der gestiegenen Anzahl (30 bis 40 Ausgangsrechnungen pro Tag) nicht
mehr auf die Poststelle mitnimmt und dadurch ein täglicher Postweg vonnöten ist.
Eine Kosteneinsparung durch Prozessoptimierung ist ebenfalls ein – wenn auch
untergeordneter – Beweggrund für das Initiieren des Projektes.
Wenngleich es in der Vergangenheit noch keine Anfragen zur elektronischen Rechnungslegung seitens Kunden gegeben hat, will Schütze-Schuhe nun auf diese Eventualität vorbereitet sein. Es gilt das Image eines hoch-technologisierten Unternehmens zu unterstreichen.
Eine Änderung der rechtlichen Rahmenbedingungen gibt ebenfalls Anlass zur Veränderung. Ein Erlass des Bundesministeriums für Finanzen (BMF-010219/0183IV/9/2005) regelt das Ende der Vorsteuerabzugsberechtigung von Fax-Rechnungen
bis Ende 2009 und ermöglicht den rechtlich gültigen Versand von elektronisch signierten Rechnungen per E-Mail.
Analyse des Integrationsbedarfs. Die Ist-Analyse umfasst den Prozess der Rechnungslegung, eine Betrachtung der technischen Gegebenheiten und die strategische
Positionierung am Markt. Der von der betrieblichen Integration betroffene Prozess ist
die Faktura, welche aus dem ERP-System heraus gedruckt wird und anschließend
manuell kuvertiert, frankiert und einmal pro Arbeitstag zur Post gebracht wird. Aus
technischer Sicht werden für den Druck einer Rechnung ein Arbeitsplatz-PC, ein
158
lokaler Laserdrucker sowie eine Frankiermaschine der Post benötigt. Die strategische Positionierung hat ebenfalls Einfluss auf die Integration. Das Unternehmen tritt
am Markt mit dem Image einer modernen Schuhfabriken Europas auf. Aus dieser IstSituation leiten sich die Ziele an eine elektronische Rechnungslegung ab:

Der gesamte Prozess der Faktura muss abgedeckt sein.

Die Möglichkeit des Versands einer Papierrechnung muss vom Lösungsanbieter genauso angeboten werden wie die elektronische Übermittlung.

Die Einfachheit der Handhabung für das Personal und die Integration in das
bestehende ERP-System muss gegeben sein.

Die rechtlichen Rahmenbedingungen der elektronischen Rechnungslegung
müssen erfüllt sein.
Design und Auswahl der Integrationslösung. Aufgrund des Fehlens einer eigenen
IT-Abteilung ist das Unternehmen auf der Suche nach einer Fertiglösung am Markt,
die die Anforderungen bestmöglich unterstützt. Es gibt eine Vielzahl von Anbietern
von elektronischer Signatur bzw. elektronischer Rechnungslegung am österreichischen Markt. Auf eine Betrachtung des gesamten Marktes wurde jedoch aufgrund
bereits bestehender persönlicher Kontakte zu zwei konkreten Lösungsanbietern
verzichtet. Eine der Lösung unterstützt nur den elektronischen Versand der Rechnungen (dh. keine Sendung via Postweg möglich), weshalb dieser Anbieter ausscheidet. Die zweite Lösung, „flexdoc“ des GRZ IT Center Linz, erfüllt auf der anderen Seite alle Anforderungen des KMU. Mit „flexdoc“ bietet das GRZ IT Center Linz
eine steuerrechtlich und revisionstechnisch korrekte Lösung für elektronische Rechnungslegung auf einer SaaS-Basis. Die Erfüllung aller K.O.-Kriterien und der persönliche Kontakt zum GRZ führen daher zu einer Umsetzungsentscheidung für „flexdoc“.
Realisierung der Integrationslösung. Nachdem die Entscheidung zugunsten
„flexdoc“ gefallen ist, wird zwischen den Integrationspartnern GRZ IT Center und
Schütze-Schuhe ein Vertrag unterzeichnet, in dem alle Services durch das GRZ IT
Center und die Beauftragungen durch Schütze-Schuhe fixiert sind. Das Geschäftspapier von Schütze-Schuhe wird von deren Druckerei angefordert und dem GRZ
elektronisch übermittelt. Die Korrektheit des Layouts wird nach der Einbindung durch
das GRZ von Schütze-Schuhe vorab kontrolliert. Die Integration und Konfiguration
von „flexdoc“ in das bestehende System als Druckertreiber wird durch den externen
EDV Dienstleister von Schütze-Schuhe durchgeführt und erfordert in Summe ca. 2
Stunden an Aufwand.
Betrieb und kontinuierliche Verbesserung. Nach einer kurzen telefonischen
Einschulung des GRZ kann die elektronische Rechnungslegung mit „flexdoc“ von
einem Tag auf den anderen in Produktivbetrieb gehen. Da Schütze-Schuhe die
159
Software als Service auf der Infrastruktur des GRZ in Anspruch nimmt, obliegt die
Wartung, Anpassung und Weiterentwicklung von „flexdoc“ dem GRZ.
Durch die Umstellung auf eine elektronische Rechnungslegung werden keine neuen
Geschäftsfelder erschlossen, jedoch wird eine zusätzliche Dienstleistung durch die
neue Möglichkeit der Rechnungslegung zum Portfolio von Schütze-Schuhe hinzugefügt. Die Strategie eines modernen Unternehmens wird dadurch nochmals bekräftigt.
Der Prozess der Rechnungslegung wurde insofern verändert, dass alle Arbeiten, die
nach dem Senden des Dokumentes an den Drucker erfolgten (Kuvertierung, Frankierung, Postweg), an das GRZ ausgelagert wurden. Abbildung 48 zeigt sowohl den
Prozess der Fakturierung als auch die betroffenen technischen Komponenten in der
Zentrale des GRZ. Der Prozess lässt sich nun wie folgt charakterisieren:
1. Über das Webportal von „flexdoc“ stellt Schütze-Schuhe ein, wie der Versand
der Dokumente (in diesem Fall die Rechnungen) an die einzelnen Empfänger
erfolgen soll. Dies ist pro Kunde einmal einzustellen und nur bei Änderungen
bzw. Anlage von Neukunden erneut durchzuführen.
2. Schütze-Schuhe startet einen neuen Rechnungslauf. Dabei verhält sich
„flexdoc“ wie ein Druckertreiber. Anstatt die Dokumente lokal auszudrucken,
werden die Daten an das Web Service von „flexdoc“ gesendet.
3. Die Versandart wird vom GRZ über die im Webportal getroffenen Einstellungen für jeden Empfänger ermittelt. Folgende Versandarten können abgewickelt werden:
a. Dokumenteingang im gewünschten Format: Akzeptiert der Empfänger
elektronische Rechnungslegung und ist im Webportal registriert (in der
Abbildung: Empfänger A), erhält er das Dokument per E-Mail als signiertes PDF. Falls gewünscht wird es zusätzlich in einem anderen empfängerspezifischen Format (SAP iDoc, ebInterface, XML, UN/EDIFACT
oder CSV) gemeinsam mit einer Prüfdatei, welche die Gültigkeit der
elektronischen Signatur zum Zeitpunkt der Unterzeichnung dokumentiert, übermittelt. Eine Überprüfung der Signatur bzw. Weiterverarbeitung in der gewünschten Applikation ist dadurch gesichert. Über das
Webportal kann der Empfänger seine Dokumente einsehen, im gewünschten Format downloaden, prüfen und archivieren.
b. Dokumenteingang als E-Mail: Akzeptiert der Empfänger elektronische
Rechnungslegung, ist aber nicht im Webportal registriert (in der Abbildung: Empfänger B), erhält er das Dokument per E-Mail als signiertes
160
PDF an die vom Versender angegebene E-Mail-Adresse. Eine Überprüfung der Signatur ist ebenso möglich.
c. Übermittlung per Post: Für jene Empfänger, die ihre Dokumente weiterhin in Papierform benötigen (in der Abbildung: Empfänger C), werden
diese vom GRZ ausgedruckt, kuvertiert und versandt („Fulfillment“).
4. Vom Versand erhält der Versender eine Benachrichtigung per E-Mail mit einer
positiven oder negativen Statusmeldung.
Abbildung 48: Überblick über die Integrationslösung mit „flexdoc“ (eigene Darstellung)
Die Firma Schütze-Schuhe nutzt „flexdoc“ derzeit ausschließlich für Ausgangsrechnungen. Die Rechnungen werden noch zu 99% seitens GRZ gedruckt und per Post
versendet. Lediglich ein Kunde nimmt derzeit von der elektronischen Übermittlung
Gebrauch. Der Grund dafür wird neben der gefestigten Ideologie des Ausdruckens
von Dokumenten vor allem im geduldeten, verlängerten Zahlungsziel (insbes. auch
Skonto), das durch den traditionellen Postweg entsteht (Rechnungseingang erst 1-3
Tage später als bei elektronischer Rechnung), vermutet.
Die Einsparungen in Zeit sind jedoch beträchtlich und die Kosten verringern sich
durch das Outsourcing des Prozesses ebenfalls, da auch die Kosten für den postalischen Versand eines Dokumentes über „flexdoc“ um 12,6% niedriger sind als bei
einem Eigenversand. Durch den elektronischen Versand von Dokumenten über
161
„flexdoc“ sind einer Kalkulation zur Folge Einsparungen von bis zu 62% pro Brief546
möglich.
In Abbildung 49 sind die linearen Kostenfunktionen der bisherigen Lösung sowie die
von „flexdoc“ bei einem Anteil von 1%, 50% und 100% an elektronischen Dokumenten dargestellt. Die Schnittpunkte mit der bisherigen Lösung zeigen, dass „flexdoc“
ab dem 3054. Dokument bei einem Anteil von 1% an elektronischen Dokumenten, ab
dem 1074. Dokument bei einem Anteil von 50% an elektronischen Dokumenten und
bereits ab dem 646. Dokument, wenn alle Dokumente elektronisch versendet werden, kostengünstiger ist als die alte Lösung. Für Schütze-Schuhe bedeutet dies,
dass „flexdoc“ ab dem Versand des 3054. Dokuments – das ist etwa im 4. Monat der
Nutzung - wirtschaftlicher ist als die bisherige Lösung.
3500
bisherige Lösung
3000
3054
flexdoc (1% elektronische Dokumente)
Kosten (in EUR)
2500
2000
1500
1074
1000
646
500
0
0
500
1000
1500
2000
2500
3000
3500
Anzahl Dokum ente
Abbildung 49: Kostenfunktion der bisherigen Lösung und mit „flexdoc“ (eigene Darstellung)
Das Anwendungsszenario der betrieblichen Integration zeigt, dass eine Aufhebung
von Medienbrüchen durch deren Digitalisierung mittels Informationstechnologie zu
durchgängigen, automatisierbaren Prozessen führt. Umso automatisierter der Prozess ist, desto höher ist das Einsparungspotenzial für das Unternehmen. SchützeSchuhe nutzt zwar die elektronische Rechnungslegung, allerdings sind weitere
Einsparungen durch die Erhöhung der Quote an elektronischen Rechnungen gegenüber gedruckten Rechnungen erreichbar. Aber auch bei der gedruckten Rechnung
konnten durch Outsourcing der Rechnungslegung zusätzliche Ressourcen im Unternehmen eingespart werden, was sich auf der Kostenseite positiv auswirkt.
546
Basis der Berechnung: Briefe bis 20 Gramm im Inland (Österreich) im Juni 2008.
162
6.4 Fallstudie 3: Middleware zur Integration (Schuller)
Die Schuller Eh’Klar GmbH, ein auf Malerbedarf spezialisiertes KMU, muss auf die
Anforderung eines Großkunden reagieren, der eine Unterstützung der EDI-basierten
Standardnachricht „DESADV“ zur elektronischen Meldung von Lieferungen fordert.
Diese Anforderung löst ein gesamtbetriebliches Projekt aus, in dem das in die Jahre
gekommene ERP-System durch ein neues System abgelöst und um Middleware zur
Integration erweitert wird.
Die Unternehmensgruppe Schuller (Schuller Eh’Klar GmbH) verfügt über Firmensitze
in 10 europäischen Ländern (Tochterfirmen mit Mehrheitsbeteiligungen) und Partnerfirmen in weiteren 5 europäischen Ländern. Die Tochterfirmen beschäftigen gesamt
ca. 70 Mitarbeiter, das Hauptaufgabenfeld ist der Vertrieb der Waren. Der Firmensitz
ist Wien, es wird allerdings keine eigene Niederlassung betrieben. Am zentralen
Standort in St. Florian wird für alle Tochterfirmen das Produktsortiment bestimmt und
der Wareneinkauf übernommen. Das Unternehmen beschäftigt am Standort St.
Florian etwa 80 Mitarbeiter. Der Geschäftsführer (CEO) ist Herr Karl-Heinz Schuller.
Der Firmensitz in St. Florian ist klassisch in die Abteilungen Einkauf (inkl. Marketing,
Bestellwesen, Abwicklung und CEO), Rechnungswesen, Verkauf (eingeteilt in Regionen Österreich, Deutschland, Export & Tochterfirmen), Außendienst (für Österreich), Lager (größte Abteilung mit ca. 50 Personen, kein eigener Fuhrpark vorhanden).
Das Unternehmen positioniert sich als Komplettanbieter rund um den Malerbedarf
wie Pinseln, Bürsten, Farbrollern, Spachteln, Handschuhen, Schleifmitteln und weiteren Produkten. Schuller setzt seit mittlerweile 35 Jahren auf professionelle Kundenbetreuung und beste markterprobte Qualität.
Schuller hat mehr als 150 Lieferanten, wobei der Einkauf der Waren etwa zur Hälfte
in Asien und zur anderen Hälfte in Europa (vor allem Deutschland, Tschechien,
Polen und Italien) erfolgt. Zu den umsatzstärksten Produkten zählen Farbsprays und
Klebebänder, die in Asien eingekauft werden. Der Wettbewerb ist vor allem in Ländern, in denen Schuller wenige Marktanteile besitzt, sehr stark. Zu den Kunden zählt
der gesamte Großhandel (Metro, Hornbach, Lagerhaus, Bauhaus, Baumaxx, Quester, Spar Gruppe, Hagebau, Beinkofer, usw.) sowie der Fachhandel.
Die Firma Schuller besitzt keine eigene IT-Abteilung. Dementsprechend fehlt ein
(Haupt-)Verantwortlicher für die Informations- und Kommunikationstechnik, darüber
hinaus gibt es aber keine schriftlichen Strategien bzw. Richtlinien in diesem Bereich.
Um dies zu kompensieren wurden drei „Key-Nutzer“ benannt, welche als Ansprech-
163
partner für IT-Belange gelten. Das Firmennetzwerk und die technische Büroausstattung werden über einen externen IT-Dienstleister betreut, welcher über einen Remote-Zugang („Terminaldienst“) im Notfall auf die Inhouse betriebenen Server und
Arbeitsplatz-PCs Zugriff hat.
Feststellen des Integrationsbedarfs. Der Auslöser für das gegenständliche Integrationsprojekt ist die Anforderung seitens eines Großkunden, welcher Schuller die
zusätzliche Verwendung der EDI-basierten Standardnachricht „DESADV“ zur Meldung von Lieferungen vorschreibt. Eine Liefermeldung mittels DESADV beschreibt
Einzelheiten über Waren, die unter vereinbarten Bedingungen geliefert worden sind
oder zur Lieferung bereit stehen. Dieser Standard wird vom unternehmensweit im
Einsatz befindlichen ERP-System derzeit nicht unterstützt. Seitens Kunden wird die
Adaptierung des Standards nach mehrmaliger Verlängerung der Frist bis Anfang
2009 gefordert. Bei einem Verzug der Unterstützung ist bereits eine Pönale im Gespräch und in letzter Konsequenz kann die fehlende Integration zum Ausschluss aus
dem Wertschöpfungsnetzwerk führen.
Das Geschäftsmodell des Unternehmens ist stark auf den Verkauf der Waren in den
Geschäften der Großkunden ausgerichtet. Der Wegfall eines Großkunden hat erhebliche finanzielle Einbußen zur Folge und ist mit allen Mitteln zu vermeiden. Zusätzliche finanzielle Konsequenzen durch Pönale wie beispielsweise bei der Nichteinhaltung von Lieferterminen sind in dieser Branche üblich. Zuverlässige und stabile
Kooperationen sind daher Voraussetzung für eine sichere Geschäftstätigkeit im
Umfeld des gegenständlichen Wertschöpfungsnetzwerks.
Analyse des Integrationsbedarfs. Basierend auf der strategischen Entscheidung
des Top Management, die Anforderung des Großkunden zu erfüllen, wurde einer der
Inhouse „Key-Nutzer“ mit dem Integrationsprojekts betraut. Eine kurze Ist-Analyse
der organisatorischen Rahmenbedingungen, der beteiligten Prozesse und der ITInfrastruktur zeigten, dass das ERP-System Innova, ein Warenwirtschaftssystem für
den Mittelstand, eine kritische Position in der Erfüllung der Anforderung spielen
würde. Das System wurde vor ca. 15 Jahren eingeführt und ist in technologischer
Hinsicht mittlerweile nicht mehr zeitgemäß. Obwohl die Daten in einer Datenbank
abgelegt werden, wurde eine Portierung auf eine grafische Benutzeroberfläche nie
vorgenommen. Bedingt durch die veraltete Technologie können Büroanwendungen
(wie Microsoft Office) nicht an das bestehende ERP-System angebunden werden.
Zusätzlich kommt hinzu, dass das System standardmäßig keine EDI-Standards zum
elektronischen Austausch von Daten unterstützt. Die beiden EDI-Nachrichten „ORDERS“ und „INVOIC“ werden bereits unterstützt, diese wurden allerdings für jeden
164
Großhändler individuell programmiert. Dies erweist sich bei Änderungen und Erweiterungen durch die mangelnde Flexibilität und Anpassbarkeit als äußerst nachteilig.
Design und Auswahl der Integrationslösung. Für das Unternehmen ergeben sich
zwei alternative Möglichkeiten zur Lösung der geänderten Anforderungen:

Eine Anpassung des bestehenden ERP-Systems Innova durch den bisherigen
Softwareentwicklungspartner wird in Betracht gezogen. Die derzeitige Schnittstelle muss dazu von einem externen Softwaredienstleister individuell angepasst (ORDERS bzw. INVOIC) und erweitert (DESADV) werden.

Ablösung des bestehenden ERP-Systems Innova und Einführung einer neuen,
moderneren ERP-Lösung.
Für beide Alternativen benötigt Schuller aufgrund mangelnden Know-Hows einen
externen Dienstleister. Nicht die Kenntnis des Marktes, sondern die aktive telefonische Akquise des Dienstleisters Xynamics Information Engineering GmbH, führen
schlussendlich zu einer Umsetzungsentscheidung zugunsten der Ablösung des
bestehenden ERP-Systems. Eine erneute Individualprogrammierung zur Unterstützung der DESADV-Nachricht wäre zwar durchaus denkbar, maßgeblich gegen diese
Lösung spricht aber die veraltete Technologie. Für eine vollständige Umgestaltung
der betrieblichen Informationssysteme sind vor allem qualitative Ziele ausschlaggebend. So verspricht sich die Geschäftsführung von der Ablösung des ERP-Systems
Zukunftssicherheit und Ausbau der Integrationsfähigkeit durch den Einsatz von
Softwarelösungen eines marktdominanten, internationalen Players. Gleichzeitig
sollen damit Anforderungen an Mehrsprachigkeit und andere rechtlichen Rahmenbedingungen bei einem späteren unternehmensweiten Rollout in allen Tochterfirmen
erfüllt werden.
Bei einem persönlichen Gespräch der Geschäftsführer der beiden Unternehmen
Schuller und Xynamics wird die weitere Vorgehensweise im Projekt festgelegt. Der
Geschäftsführer von Xynamics Hr. DI (FH) MBA Harald Konnerth bleibt im gesamten
Projektverlauf Ansprechperson und Koordinator. Die Wahl fällt auf das ERP-System
„Microsoft Dynamics AX“ und die Integrations-Middleware „Microsoft BizTalk“.
Realisierung der Integrationslösung. Die Umsetzung der Integrationslösung erfolgt
teilweise parallel mit der Ablösung des bestehenden ERP-Systems in folgenden
Phasen:

Technische Analyse der B2B Schnittstellen des bestehenden ERP-Systems
(Aufwand am Gesamtprojekt ca. 10%)
165

Soll-Konzeption der in BizTalk umzusetzenden alten Schnittstellen (ORDERS
und INVOIC) sowie Konzeption der neuen DESADV-Nachricht (Aufwand am
Gesamtprojekt ca. 20%).

Spezifikation der benötigten Hardware und Software für die Umsetzung der
Integrationslösung (Aufwand am Gesamtprojekt ca. 10%).

Inbetriebnahme der Hardware und Installation der Software, Anwenderschulung sowie Implementierung der benötigten EDI-Nachrichten für die Integration
(Aufwand am Gesamtprojekt ca. 60%).
Betrieb und kontinuierliche Verbesserung. Wie bei EDI Implementierungen üblich
und auch seitens Kunden gefordert, beginnt der Austausch mit einem einmonatlichen
Testbetrieb. In der Testphase laufen das alte und neue System im Parallelbetrieb,
dh. der Lieferschein wird in Papierform und als elektronische EDI-Nachricht
„DESADV“ übermittelt. Nach erfolgreichem Abschluss des Testbetriebes kann die
prototypische Integrationslösung wie geplant zeitgerecht in den Echtbetrieb übergehen.
Die Voraussetzungen für einen weiteren Ausbau der elektronischen Kommunikation
zwischen Großhändler und Schuller sind nun vorhanden und können durch die
Implementierung von zusätzlichen EDI-Nachrichten mit der vorhandenen Infrastruktur
umgesetzt werden. Zu nennen wäre hierbei der Austausch von Katalogdaten über
die Nachricht „PRICAT“, oder die Anbindung zusätzlicher Großhändler auf EDI-Basis
(oder auch anderer Standards). Eine Anbindung der Vertreter und der weiteren
Niederlassungen sind ebenfalls bereits angedacht.
Durch die Umsetzung der Integration werden keine neuen Geschäftsfelder erschlossen, vielmehr geht es darum, die bestehenden Kunden zu erhalten. Als neue Serviceleistung kann Schuller nun seinen Kunden eine B2B Anbindung aktiv anbieten,
da eine Integration zusätzlicher Kunden nun kurzfristig und effizient möglich ist. Der
Prozess einer Bestellungsabwicklung für Kunden mit B2B Anbindung lässt sich nun
wie folgt charakterisieren (siehe Abbildung 50):
1. Der Großhandelskunde schickt eine standardkonforme ORDERS-Nachricht an
Schuller. Der BizTalk Server empfängt die Nachricht und wandelt diese in das
gewünschte, für das interne ERP-System verständliche Zielformat um. Da die
166
Kommunikation derzeit technisch über das X.400-Netz547 erfolgt, wird der Erhalt der Bestellung nicht bestätigt. Die Bestellung wird intern abgearbeitet.
2. Die Bestellung ist versandbereit. Aus dem ERP-System wird ein Lieferaviso
generiert, welches vom BizTalk Server in das gewünschte Zielformat
(DESADV-Nachricht) konvertiert und elektronisch an den Empfänger gesendet
wird.
3. Die Waren werden (inklusive zusätzlichem Lieferschein in Papierform) an den
Spediteur übergeben, welcher diese an den Empfänger liefert.
4. Die Waren sind geliefert. Aus dem ERP-System wird eine Rechnung generiert,
welche vom BizTalk Server in das gewünschte Zielformat (INVOIC-Nachricht)
konvertiert und elektronisch an den Empfänger gesendet wird.
Abbildung 50: Überblick über die Integrationslösung der Fallstudie „Schuller“ (eigene Darstellung)
Abbildung 50 zeigt neben der Prozesssicht die wichtigsten technischen Komponenten für den Betrieb der Integrationslösung aus der Sicht von Schuller. Die Kernkomponente der Integration ist der Microsoft BizTalk Server. Der BizTalk Server dient zur
Unterstützung, Integration, Verwaltung und Automatisierung von Geschäftsprozessen
sowohl innerhalb eines Unternehmens als auch unternehmensübergreifenden.
BizTalk ruft die elektronische Nachrichten ab, konvertiert diese und führt die Kommunikation zwischen heterogenen Systemen durch und überwacht diese. Über soge-
547
X.400 ist ein E-Mail-System (also eine Alternative zum Internet E-Mail), das häufig als Kommunikationsstandard im professionellen EDI-Nachrichtenaustausch verwendet wird. Vgl. ISO/IEC 100211:2003
167
nannte Adapter oder standardisierte Schnittstellen lassen sich nun beliebige Kunden
mit unterschiedlichen Formaten flexibel elektronisch anbinden.
Eine Beurteilung der Wirtschaftlichkeit der Integrationslösung ist seitens Schuller
nicht durchgeführt worden. Wirtschaftlichkeitsüberlegungen wie Kosteneinsparungen
oder Effizienzsteigerungen waren nicht vorrangige Ziele der betrieblichen Integration.
Durch die Integration konnten auch keine direkten Einsparungen erzielt werden.
Damit zeigt die Fallstudie eine typische EDI Implementierung nach dem „Hub-andSpoke“ Prinzip. Der Initiator („Hub“) versucht proaktiv den kleineren Unternehmen
(„Spokes“), vorwiegend Lieferanten, die Einführung von Informationssystemen zum
Austausch von EDI-Nachrichten durchzusetzen. Eine latente Drohung die Geschäftstätigkeit einzustellen verleiht dabei der Umsetzung noch den nötigen Nachdruck.
Studien haben allerdings nachgewiesen, dass der Initiator dadurch zwar zuerst mehr
gewinnt, aber auf lange Sicht gesehen alle Parteien von der Umsetzung profitieren548.
Das Hauptziel der betrieblichen Integration war die Erfüllung der Anforderungen des
Großkunden. Dies konnte durch das neue ERP-System in Verbindung mit der Middleware zur Integration in der vorgegebenen Zeit erreicht werden. Die notwendigen
einmaligen Investitionskosten des Integrationsprojekts werden von Schuller als
notwendige Modernisierungsmaßnahmen betrachtet. Zukunftssicherheit und Erweiterbarkeit der Integrationslösung waren Schuller ebenfalls sehr wichtig. Dies sollte
durch den Einsatz von Softwarelösungen des marktdominanten, internationalen
Players Microsoft gegeben sein. Durch die Schaffung der technischen Voraussetzungen können nun weitere Niederlassungen angebunden sowie weitere Kundenbindungsmaßnahmen getätigt werden.
6.5 Fallstudienvergleich
Die Fallstudien werden zunächst in den Bezugsrahmen aus Kapitel 3 eingeordnet,
was einen Vergleich hinsichtlich der Grundlagen betrieblicher Integration (Strategie,
Integrationsdimensionen und Integrationsebenen) ermöglicht. Daran anschließend
wird die Vorgehensweise bei der Integration analysiert und deren Gemeinsamkeiten
und Unterschiede bestimmt, um ein erstes Vorgehensmodell abzuleiten.
6.5.1 Vergleich im Bezugsrahmen
Die drei Fallbeispiele behandeln individuelle, nachhaltige Integrationslösungen und
die angewandten Konzepte, Technologien und Standards bei der Umsetzung auf
548
Vgl. Premkumar (2000, S. 61)
168
unterschiedlichen Ebenen. Der in den Grundlagen erarbeitete Bezugsrahmen zur
Betrachtung einer betrieblichen Integration auf verschiedenen Ebenen und unter
unterschiedlichen Dimensionen lässt sich auch für die Fallstudien anwenden. Abbildung 51 zeigt die Einbettung der Fallstudien in diesen Bezugsrahmen.
Abbildung 51: Einbettung der Fallstudien in den Bezugsrahmen (eigene Darstellung)
Das Vorhandensein einer Strategie zur Integration mit internen und externen Stakeholder (z.B. standortübergreifend agierende Abteilungen, Partnerunternehmen,
Lieferanten und Kunden) wird als eine notwendige Voraussetzung für die Realisierung von Integrationslösungen gesehen. Auch in den betrachteten Fallstudien wurde
die betriebliche Integration strategisch geleitet. In der Abbildung ist die Strategie als
halb gefüllter Kreis dargestellt, da diese von den KMUs nicht bzw. nicht ausreichend
dokumentiert war.
Wie auch in der Abbildung ersichtlich, wurden alle drei Integrationsdimensionen in
den Fallstudien adressiert. Ein gefüllter Kreis bedeutet hier, dass ein Faktor aus
dieser Dimension bereits als ausschlaggebend für den Integrationsbedarf explizit
genannt wurde. Ein halb gefüllter Kreis bedeutet, dass die Dimension ebenfalls
relevant für die Realisierung der Integrationslösung war, diese aber nicht als Auslöser galt und diese auch im weiteren Projektverlauf nicht weiter beachtet wurde. Der
technologische Faktor „relativer Vorteil“ mit den dadurch bedingten Kosteneinsparungen und Qualitätsverbesserungen spielte in den Fallstudien 1 und 2 eine wichtige
Rolle. Aus den organisatorischen Faktoren war bei allen Fallstudien die Top Management Unterstützung relevant. Der strategische Wert des Technologieeinsatzes
wird bei den Fallstudien 2 und 3 als Faktor angegeben. Zusätzlich werden bei Fallstudie 2 die Ressourcenverfügbarkeit (Personal) sowie die positive Grundeinstellung
gegenüber der Technologie genannt. Bei allen Fallstudien wurden auch Faktoren aus
dem betrieblichen Umfeld relevant. Die Wettbewerbsintensität war der primäre Einflussfaktor bei Fallstudie 1. Bei Fallstudie 3 wurde dieser Faktor ebenfalls genannt.
Für die Fallstudie 2 war zusätzlich der regulative Rahmen und bei Fallstudie 3 der
Industriestandard (Branche) relevant für die betriebliche Integration.
Aus Sicht der Integrationsebenen lässt sich für die analysierten Fallstudien feststellen:
549
169

Alle drei Fallstudien behandeln eine Integration auf Ebene der Prozesse
und Services: Durch Outsourcing wesentlicher Kernprozesse der ABC GmbH
an Büroprofi findet in Fallstudie 1 eine Integration auf Ebene der Geschäftsprozesse statt. Hier wird das gesamte Wertschöpfungsnetzwerk eingebunden,
um eine effiziente Lieferung vom Hersteller direkt oder auch indirekt zum Endverbraucher zu ermöglichen. In Fallstudie 2 wird der Prozess der Rechnungslegung von Schütze-Schuhe an einen SaaS-Anbieter ausgelagert. Und in Fallstudie 3 wird der Prozess der Bestellungsabwicklung von Schuller für die Kunden mit B2B Anbindung durch den elektronischen Versand von Dokumenten
(Bestellung, Lieferschein und Rechnung) medienbruchfrei gestaltet.

Keine der Fallstudien weist eine Integration auf sozialer Ebene auf. Dies
lässt sich darauf zurückführen, dass der Durchführungszeitraum der Integration der Fallstudien zwischen 2004 und 2008 lag. Konzepte und Technologien
zur Integration auf sozialer Ebene finden erst in den letzten Jahren in der Praxis und Wissenschaft Beachtung549. Hier besteht daher eine Lücke an integrierten Umsetzungen und Best Practice Beispielen.

In zwei Fallstudien wurde dedizierte Middleware zur Integration verwendet.
In Fallstudie 1 verwendet Büroprofi den IBM WebSphere Application Server,
Konverter der Firma Seeburger sowie Inobit Software zur Anbindung der
KMUs, Hersteller und Spediteure. In Fallstudie 3 findet die Anbindung unterschiedlicher Formate über Microsoft Biztalk statt.

Betriebliche Informationssysteme spielen ebenfalls in allen drei Fallstudien eine Rolle in der Integration. In Fallstudie 2 wird die elektronische Rechnungslegung über einen Druckertreiber eingebunden, der auch vom ERPSystem verwendet wird. Hier sind daher betriebliche Informationssysteme aus
Sicht der Integration nur am Rande beteiligt. Wesentlich hingegen sind die betrieblichen Informationssysteme in den beiden anderen Fallstudien. In Fallstudie 1 ist das ERP-System „CIPS“ vollständig zwischen Büroprofi und der ABC
GmbH integriert. Zusätzlich ist SAP von den Spediteuren angebunden. Ebenso ist das eingesetzte ERP-System in Fallstudie 3 für die Integration der Bestellungsabwicklungen essenziell.

In allen drei Fallstudien wird eine Integration auf Ebene der Daten vollzogen. Über eine individuell entwickelte Schnittstelle auf der Basis von WebEDI
werden in Fallstudie 1 die Aufträge, Kundendaten, kundenindividuelle Preise,
Kataloge, Auftragsbestätigungen sowie elektronische Lieferscheine zwischen
Büroprofi und „CIPS“ ausgetauscht. Zusätzlich werden – je nach angebunde-
Integration mittels Enterprise 2.0 Technologien stellt gemäß Argumentation in Kapitel 3.1 (vgl.
Tabelle 1) die vierte Phase betrieblicher Integration dar, die etwa seit Mitte der 2000er in Wissenschaft
und Praxis diskutiert werden.
170
nem Spediteur und Hersteller – unterschiedliche Konverter basierend auf
XML, dem Standard UN/EDIFACT sowie SAP iDoc eingesetzt. Datenschnittstellen werden in Fallstudie 2 vom SaaS-Anbieter verwendet, um die Rechnungen in empfängerspezifische Formate (SAP iDoc, ebInterface, XML,
UN/EDIFACT oder CSV) zu konvertieren. Auch in Fallstudie 3 spielt die Datenebene eine wichtige Rolle, um EDI-basierte Standardnachrichten (ORDERS, INVOIC, DESADV) auszutauschen.
6.5.2 Vergleich der Vorgehensweise bei der Integration und Modellbildung
Die Fallstudien sollen nun anhand der Vorgehensweise bei der Integration analysiert
werden. Die Beschreibung in den Vorgehensweisen wurde in die in Kapitel 5.4 hergeleiteten Phasen „Orientierung“, „Analyse“, „Design“, „Realisierung“ und „Betrieb“
unterteilt. Der Fokus des Fallstudienvergleichs liegt dabei an den einzelnen Aktivitäten und erzielten Resultaten in diesen Phasen. Das Ziel ist, ein allgemeines Vorgehen in den Fallstudien zu identifizieren.
Abbildung 52 illustriert die Hauptphasen mit deren Aktivitäten und Ergebnisse. Die
Abbildung zeigt ferner die Ausführung von bestimmten Aktivitäten in den erhobenen
Fallstudien. Ein gefüllter Kreis zeigt an, dass die spezifische Aktivität in der Fallstudie
durchgeführt wurde, ein nicht gefüllter Kreis das Gegenteil. Ein halb gefüllter Kreis
bedeutet, dass die Aktivität in der Fallstudie zwar adressiert wurde, aber entweder
nicht systematisch durchgeführt oder nicht explizit dokumentiert wurde.
171
Abbildung 52: Vorgehensweise bei der Integration in den Fallstudien (eigene Darstellung)
Aus Sicht des Vorgehens bei der betrieblichen Integration lässt sich für die drei
Fallstudien feststellen:

In allen drei Fallstudien hatte das untersuchte Unternehmen einen spezifischen Bedarf, die Art die Geschäftstätigkeit auszuführen, zu ändern. Der
Handlungsbedarf wurde von Einflussfaktoren aus unterschiedlichen Dimensionen (Technologie, Organisation, Umfeld) bestimmt. Basierend auf strategischen Überlegungen, entschied in allen drei Fällen das Top Management über
die Durchführung einer betrieblichen Integration. Der Integrationsbedarf wurde
in keinem Fall explizit in einer Strategie dokumentiert. Diese Aktivitäten sind
der Orientierungsphase (Phase 1) zuzuordnen.

Die zweite Phase, die Analyse wurde in allen Fällen nur unvollständig
durchgeführt und wenn überhaupt, nicht ausreichend dokumentiert. Analysiert wurden die Organisation (Aufbau- und Ablauforganisation), Rahmenbedingungen aus dem betrieblichen Umfeld, involvierte Geschäftsprozesse und
172
die technische Infrastruktur. In zwei Fällen wurden die Ziele der Integration in
einer Anforderungsdefinition zusammengeführt.

Ebenso wurde in den Beispielen kein methodisch fundierter Ansatz in der
Entwurfsphase (Design) verfolgt. Für die Umsetzung der Integrationslösung
wurde zwar in allen Fällen ein passender Partner gefunden, dies passierte jedoch mehr durch Zufall. Es war kein Überblick über mögliche Ansätze und
Konzepte zur betrieblichen Integration vorhanden und kein Marktüberblick
über Werkzeuge, Standards oder Partner für die Integration. In Fallstudie 3
wurde zusätzlich der zu verwendende Standard explizit von einem Kunden
vorgegeben.

Die Realisierung der Integrationslösung war zwar in den drei Fällen sehr
unterschiedlich, die notwendigen Schritte für die Implementierung wurden aber
unter Anleitung und Leitung des Integrationspartners gründlich durchgeführt
und dokumentiert. Der Partner übernahm auch die Einschulung der Anwender und gegebenenfalls der Systemadministratoren in die neuen Systeme.
Das Ziel von Fallstudie 1 war möglichst früh einen Prototyp zu realisieren, der
daraufhin in weiteren Rollouts verbessert wurde. Die elektronische Rechnungslegung aus Fallstudie 2 war in der Implementierung nicht komplex, weshalb mit dieser nach kurzem Test sofort der Produktivbetrieb aufgenommen
wurde. In Fallstudie 3 wurde für einen definierten Zeitraum ein Parallelbetrieb
zwischen alter und neuer Lösung aufgenommen, um die prototypische Implementierung zu validieren.

Die Evaluierung der realisierten Lösung variiert zwischen den Fallstudien
stark. Alle drei Integrationslösungen wurden von den betroffenen Firmen als
erfolgreich bezeichnet, da ein Produktivbetrieb aufgenommen und die gesetzten Ziele der Integration grundsätzlich erreicht wurden. Nur in Fallstudie 1 führt
der Partner umfangreiches laufendes Monitoring und kontinuierliche Verbesserungen der Lösung durch und bietet auch verschiedene Möglichkeiten zur
Evaluierung über mehrere Arten des Feedbacks der angebundenen Einzelhändler an. In der Fallstudie 2 wurde eine Kosten-Nutzen-Rechnung des Projekts durchgeführt, der Anbieter ist alleinig für die Weiterentwicklung verantwortlich. In der Fallstudie 3 wurde die Integrationslösung selbst nicht evaluiert,
eine Weiterentwicklung der Lösung aber angedacht.
6.6 Zusammenfassung
In diesem Kapitel wurden die Möglichkeiten zur Umsetzung individueller betrieblicher
Integrationen anhand mehrerer Fallstudien systematisch erhoben und ein Mehrfachfallstudienvergleich in der Form von Stärken-Schwächen Profilen durchgeführt. Der
Vergleich wurde zunächst auf Basis des Bezugsrahmens beschrieben. Danach
173
wurden die wesentlichen Aktivitäten und Ergebnisse bei der Vorgehensweise der
Integration festgehalten und den Hauptphasen zugeordnet. Damit konnte die wissenschaftliche Fragestellung (FS4) beantwortet werden. Zusammenfassend lässt sich
feststellen:

Die drei Fallstudien zeigten erfolgreiche Beispiele einer betrieblichen Integration. Obwohl in verschiedenen Branchen angesiedelt und mit Konzepten auf
unterschiedlichen Ebenen durchgeführt, folgten die analysierten Fälle insgesamt einem gemeinsamen Vorgehen. Dies ist in Übereinstimmung mit Alt
et al., da diese Autoren auch annehmen, dass Kooperationen zwischen Unternehmen nicht nur gemeinsame Merkmale zeigen, sondern auch Gemeinsamkeiten in ihrer Umsetzung aufweisen550. Auch Stolzenberg und Heberle
sehen, dass es trotz aller Unterschiede in Veränderungsprozessen auch
grundlegende Gemeinsamkeiten gibt551. Gemeinsame Aktivitäten und Ergebnisse bei der Integration wurden abgeleitet und in eine erste Modellbildung
aufgenommen.

Sowohl in den wissenschaftlichen Ansätzen552, als auch in den Beispielen aus
der Wirtschaft zeigen eine Lücke auf der soziale Ebene. Bedingt durch die
noch junge Vergangenheit von Konzepten und Technologien auf dieser Ebene, sollen Pilotprojekte speziell die soziale Ebene adressieren und die Vorgehensweise bei der betrieblichen Integration aufzeigen.

Obwohl es sich bei den Fallstudien um Beispiele erfolgreicher Integration handelt, zeigte sich auch hier, dass Bedarf in der methodischen Vorgehensweise besteht. Die Fallstudien haben offengelegt, dass vor allem in den Phasen „Analyse“ und „Design“, aber auch in der Evaluierung Unterstützungsbedarf besteht, da diese aufgrund des Fehlens einer Methodik nur unvollständig
durchgeführt wurden. Man findet Hinweise in der Literatur, dass speziell Investitionen in die IT oft unvollständig oder gar nicht evaluiert werden, da ein Mangel an anwendbaren Methoden und Werkzeugen besteht553, oder diese aus
unternehmerischen Zwang heraus angeschafft werden müssen und eine Investition daher ohnehin unumgänglich ist554. Bei KMUs spielen zusätzlich noch
die verfügbaren Ressourcen und die Zeit eine nicht unerhebliche Rolle555.
Spezieller Fokus und Aufmerksamkeit soll daher in der methodischen Unter-
550
Vgl. Alt et al. (2000a, S. 270)
551
552
Vgl. Kapitel 3.3 und 3.4
553
Vgl. Uwizeyemungu und Raymond (2009, S. 251)
554
Vgl. Schubert (2007, S. 265)
555
Vgl. Wagner et al. (2003, S. 353)
174
stützung dieser Phasen gelegt werden. In Praxisbeispielen soll die Anwendung von geeigneten Methoden zur Analyse, zum Design und zur Evaluierung
gezeigt werden.

Das Integrationsvorgehen folgt nicht notwendigerweise einer linearen
Abfolge. Die Phasen werden teilweise überlappend durchgeführt und können
in mehreren Iterationen ausgeführt werden. In der Praxis hat sich jedoch gezeigt, dass phasenorientierte Vorgehensmodelle allgemein anerkannt und verständlich sind. Deshalb sollen auch Aktivitäten und Ergebnisse in Phasen eingeteilt werden, wenngleich diese auch nicht zwingend linear ausgeführt werden.
Konsolidiertes Vorgehensmodell zur betrieblichen Integration
175
7 Konsolidiertes Vorgehensmodell zur betrieblichen Integration
Das Kapitel geht nun auf das konsolidierte Vorgehensmodell ein. Das Modell wurde
entworfen, indem es die Ergebnisse aus wissenschaftlichem Diskurs, wesentlichen
Erkenntnissen aus der empirischen Erhebung, den Fallstudien und der Anwendung
in Praxisprojekten verwendet und konsolidiert556. Damit beschäftigt sich die Zielsetzung für das Kapitel mit der Beantwortung der wissenschaftlichen Fragestellung
(FS5): Wie können die Erkenntnisse aus Wissenschaft und Wirtschaft zusammengeführt und zu einem wissenschaftlich fundierten Vorgehensmodell zur Durchführung
betrieblicher Integration verschränkt werden?
Das gegenständliche Kapitel ist wie in Abbildung 53 ersichtlich aufgebaut. Zunächst
wird das konsolidierte Vorgehensmodell in Kapitel 7.1 in zusammengefasster und
übersichtlicher Form dargestellt. Daran anschließend wird auf die Rollen im Vorgehensmodell eingegangen und eine Zuordnung zu den Aktivitäten getroffen (Kapitel
7.2). Das darauffolgende Kapitel 7.3 widmet sich inhaltlich den fünf Phasen des
Vorgehensmodells. Es werden die Aktivitäten, Methoden, Werkzeuge, Meilensteine
und Ergebnisse jeder Phase vorgestellt. Eine Zusammenfassung in Kapitel 7.4
beschließt wiederum das Kapitel.
556
176
7.1 Überblick über das Vorgehensmodell
Die gewonnenen Erkenntnisse aus Wissenschaft und Wirtschaft haben konsistent
gezeigt, dass die Einführung betrieblicher Integrationslösungen meist nicht an der
Technologie scheitert, sondern an der methodischen Unterstützung bei der Umsetzung. Ein Integrationsprojekt muss strategisch geplant werden, dabei mögliche
Konzepte auf betroffenen Integrationsebenen identifizieren und die damit verbundenen Faktoren der drei Integrationsdimensionen berücksichtigen. Neben der Technologie ist daher auf die Organisation und das betriebliche Umfeld Wert zu legen (wie
die Unternehmenskultur oder das Vertrauen in Wertschöpfungspartner, etc.). Speziell
bei der Integration auf Ebene der Prozesse und sozialer Ebene ist auf die partizipative Ausrichtung und frühzeitige Involvierung wichtiger Stakeholder zu achten. Zur
Adressierung wichtiger Erfolgsfaktoren werden daher sowohl in den einzelnen Phasen als auch phasenübergreifend geeignete Aktivitäten gesetzt und praxiserprobte
Methoden verwendet, um die benötigten Ergebnisse zu produzieren. Abbildung 54
zeigt einen Überblick über das Vorgehensmodell mit der Einteilung in die Phasen
„Analyse“, „Design“, „Realisierung“ und „Betrieb“. Darüber hinaus wurde zu Beginn
eine explizite Initialisierungsphase („Orientierung“) eingeführt.
Abbildung 54: Überblick über das konsolidierte Vorgehensmodell (eigene Darstellung)
Die für eine erfolgreiche Einführung notwendigen Rollen und Phasen werden in den
nachfolgenden Kapiteln näher beschrieben. Die Aktivitäten, Methoden und Werkzeuge sowie Ergebnisse werden im Überblick dargestellt. Beispiele zur Durchführung der
Aktivitäten und Ergebnisse aus der Anwendung der beschriebenen Methoden finden
sich bei den durchgeführten Pilotprojekten in Kapitel 8.
177
7.2 Rollen im Vorgehensmodell
Für die Durchführung von Integrationsprojekten nach dem Vorgehensmodell hat sich
eine Verteilung von folgenden Rollen als sinnvoll herausgestellt:

Projektleiter: Unternehmensinterner Projektleiter und aktiver Promoter der zu
erstellenden Integrationslösung.

(Externer) Koordinator: Koordinator des Projekts, benötigt entsprechende
Methoden- und Durchführungskompetenz und kann als externer Partner
Know-How einbringen oder auch unternehmensintern rekrutiert werden.

(Externer) Umsetzungspartner: Nimmt die Implementierung und Anpassung
der Lösung vor; kann bei entsprechender Implementierungskompetenz unternehmensintern (z.B. aus der IT-Abteilung) rekrutiert oder externes Know-How
für die Umsetzung der Integrationslösung in das Projekt eingebracht werden.

(Top-)Management des Unternehmens ist zu involvieren.

Kernteam: Das Projekt-Kernteam, bestehend aus Projektleiter, Koordinator
und wichtigen Vertretern aus den einzubindenden Abteilungen (2-5 Personen),
und ggf. externen Partnern.

Beta-Benutzer: Ausgewählter Kreis von internen Anwendern der Prototypen,
aufgeteilt in prozessspezifische Sub-Teams (auch „Beta-Tester“ oder „PilotUser“ genannt).

Pilot-Partner: Sofern eine Anbindung externer Partner vorgesehen ist, sollten
diese zuerst als Pilot-Partner im Projekt eingebunden werden, z.B. als PilotLieferant oder Pilot-Kunde.

Endbenutzer: Die Mitarbeiter des Unternehmens und damit zukünftige Nutzer
der Integrationslösung.

Administrator: Zuständige Person(en) zur administrativen Wartung der Integrationslösung.
Eine gängige Technik, um sicherzustellen, dass die Aufgaben in einem Projekt klar
verteilt sind, ist eine RACI-Matrix („Responsible, Accountable, Consulted, Informed“).
Jeder Aspekt beschreibt die Rolle einer Person im Projekt und die Art der Beziehung
zwischen ihnen und allen anderen involvierten Personen557. Die RACI Matrix eignet
sich zur Projektplanung und zum Qualitätsmanagement in Veränderungsprozessen
557
Vgl. Blair et al. (2010, S. 29); Gautier (2010, S. 1688)
178
und kann daher sehr gut für das gegenständliche Vorgehensmodell herangezogen
werden. Die vier Aspekte der RACI-Matrix stehen für558:

R: Verantwortlich („Responsible“): Personen, die für die Durchführung und
das Ergebnis der Aktivität verantwortlich sind. Sie führen die Aktivität entweder
selbst durch oder geben die Initiative für die Durchführung.

A: Rechenschaftspflichtig („Accountable“): Personen, die im rechtlichen
bzw. kaufmännischen Sinne die Verantwortung tragen. Sie tragen die Kostenverantwortung und können klare Ja/Nein Entscheidungen im Projekt treffen.

C: Beratend („Consulted“): Das sind Personen, deren Rat vor wichtigen oder fachspezifischen Entscheidungen eingeholt wird. Sie können entweder
aufgrund ihres speziellen Know-Hows zu einer Entscheidung beitragen oder
müssen aufgrund ihrer Position vor einer Entscheidung konsultiert werden.

I: Informiert („Informed“): Personen, die über den Verlauf bzw. das Ergebnis
der Aktivität zu informieren sind. Diese Personen können von der Aktivität betroffen sein und müssen daher Informationen über den Verlauf erhalten, nehmen aber nicht aktiv an der Aktivität teil.
Tabelle 29 im Anhang559 enthält einen Vorschlag einer Zuordnung von Rollen zu
Aktivitäten für das gegenständliche Vorgehensmodell. Die RACI-Matrix kann in der
jeweiligen Projektsituation je nach involvierten Personen angepasst werden.
7.3 Beschreibung der Phasen
Die folgenden fünf Unterkapitel beschreiben die Inhalte der Phasen des Vorgehensmodells.
7.3.1 Orientierung (Phase 1)
Projekte beginnen üblicherweise mit dem Bedarf einer Veränderung, der als vorteilhaft für das Unternehmen gesehen wird560. Die Orientierungsphase bietet eine
formale Vorgehensweise zur Exploration und Analyse dieses Veränderungsbedarfes.
Das Vorgehensmodell beginnt daher mit der Definition des Integrationsbedarfs
(A1.1). Wie in den Integrationsdimensionen561 hergeleitet und auch in den Fallstudien beschrieben, benötigt dieser initiale Schritt einen Auslöser. Dieser kann techni-
558
Vgl. Case et al. (2007, S. 79)
559
Siehe Anhang F: RACI-Matrix für das Vorgehensmodell.
560
561
Siehe Kapitel 3.2
179
scher oder organisatorischer Natur sein (z.B. Senkung der Nutzungskosten oder
fehlendes Know-how), aber auch durch das betriebliche Umfeld motiviert werden
(z.B. Nachfrage von einem wichtigen Kunden, rechtliche Fragen).
Ist der Bedarf gegeben, muss zunächst der Zielzustand definiert werden, den es zu
erreichen gilt: die Vision562. Daraus wird die Integrationsstrategie abgeleitet, welche
die Ziele für das Projektvorhaben vorgibt. Dafür kann es zusätzlich sinnvoll sein, eine
Vorstudie (A1.2) durchzuführen. Die Vorstudie stellt dabei eine Maßnahme zur
Sensibilisierung und Selbsteinschätzung der eigenen Bereitschaft zur betrieblichen
Integration dar. Die Bereitschaft meint einerseits die technische „Readiness“ der
Informationsinfrastruktur, etwa zum Austausch von Daten mit Partnern. Andererseits
wird auch die organisatorische „Willingness“ der eigenen Mitarbeiter zur Bereitstellung von Informationen und Mitarbeit benötigt. Die „Willingness“ der involvierten
Personen kann über eine online Befragung mittels standardisiertem Fragebogen563
oder über strukturierte Interviews564 erhoben werden.
Mit dem in den ersten Schritten geschaffenen Überblick sollte ein möglicher interner
Projektleiter und späterer Promotor dem mittleren und Top Management die Potentiale auf unterschiedlichen Integrationsebenen vorstellen (A1.3). Die Potentiale
der betrieblichen Integration können dabei mit Ergebnissen der Vorstudie aus dem
eigenen Unternehmen unterlegt werden. Auf mögliche Risiken bei mangelnder Bereitschaft zur Integration und Unterstützung des Projektes ist ebenso hinzuweisen.
Die letzte Aktivität dieser Phase befasst sich mit der Definition eines Projektes
(A1.4). Die Projektvorgehensweise, Projektziele und die für die erfolgreiche Projektdurchführung notwendigen Vereinbarungen zwischen den involvierten Partnern
müssen abgestimmt und vertraglich festgelegt werden. Auch das Planen des Projektvorgehens565 sind Teil dieser Aktivität. Ein Projektteam wird gebildet, welches
klare Rollen definiert und die notwendigen Ansprechpersonen innerhalb des Unternehmens sowie benötigte externe Partner (Kunden, Lieferanten, etc.) identifiziert.
562
563
Die Vorstudie „ePresence“ in Pilotprojekt 1 wurde mittels Fragebogen durchgeführt (siehe Kapitel
8.2).
564
In einer Vorstudie wurde in Pilotprojekt 3 mittels strukturierter Interviews das Meinungsbild erhoben
(siehe Kapitel 8.4)
565
Der Projektplan kann gegebenenfalls ein Vorgehen in mehreren Teilprojekten vorsehen. In Pilotprojekt 2 wurden drei Teilprojekt gebildet (siehe Kapitel 8.3), wobei das erste Teilprojekt der Herstellung der technischen „Readiness“ diente. Dies war die Voraussetzung für die nachfolgende Integration
der Kunden und Lieferanten.
180
Die Aktivitäten in dieser Phase stellen sicher, dass die betriebliche Integration nicht
isoliert untersucht, sondern in die strategische Planung eingebettet wird566. Ein
zentrales Ergebnis der Orientierungsphase ist die Integrationsstrategie (E1.1), welche die Ausgangssituation, Vision, Auslöser und Ziele für die Integration beinhaltet.
Auf der Basis dieser Strategie wird über die Durchführung und Finanzierung eines
Projektes entschieden567. Die Entscheidung sollte vom Top Management getragen
werden (M1.1). Bei der Einbindung eines externen Koordinators ist ein Kooperationsvertrag über den Inhalt und Umfang der Leistungen abzuschließen (E1.3). Für die
weitere Vorgehensweise ist ein Projektplan zu erstellen (E1.4). In einem Projekt KickOff werden die involvierten Personen über das Projektvorhaben informiert (M1.2).
Nachfolgende Tabellen geben einen Überblick über die Aktivitäten, Methoden und
Werkzeuge sowie Meilensteine und Ergebnisse aus dieser Phase.
Aktivitäten (A):
A 1.1: Integrationsbedarf identifizieren
Im ersten Schritt gilt es einen Überblick zu gewinnen und den grundsätzlichen Bedarf für das Unternehmen aus den Integrationsdimensionen Technologie, Organisation und betriebliches Umfeld zu identifizieren, um Vision und Ziele aus Sicht des Unternehmens abzuleiten.
A 1.2: [optional] Vorstudie durchführen
In diesem Schritt werden erste Anforderungen und Handlungsbedarfe erhoben. Dazu wird eine Bewertung der eigenen Bereitschaft zur Integration (technische „Readiness“ der Infrastruktur und organisatorische „Willingness“ betroffener Mitarbeiter) durchgeführt. Dies kann über online Fragebogen oder persönliche Interviews mit involvierten Mitarbeitern erfolgen (siehe W1.1).
A 1.3: Potentiale auf unterschiedlichen Integrationsebenen vorstellen
Ein möglicher interner Projektleiter und späterer Promotor sollte dem mittleren und Top Management die
Konzepte und Werkzeuge auf den unterschiedlichen Integrationsebenen präsentieren (siehe W1.2) und
bereits mit konkreten ersten möglichen Handlungsbedarfen für das Unternehmen unterlegen. Das
Ergebnis aus der Vorstudie sollte den identifizierten Bedarf unterstützen. Auch auf mögliche Risiken bei
mangelnder Bereitschaft zur Integration ist entsprechend hinzuweisen.
A 1.4: Projekt definieren
In diesem Schritt werden die Projektvorgehensweise, Projektziele und die für die erfolgreiche Projektdurchführung notwendigen Vereinbarungen zwischen den involvierten Partnern abgestimmt und vertraglich festgelegt. Auch das Planen des Projektvorgehens (ggf. in mehreren Teilprojekten), die Rollenverteilung im Projekt (z.B. RACI-Matrix) und die Erstellung eines ersten Projektplanes als Ergebnis sind Teil
dieser Aktivität. Das Projektteam wird formiert, welches klare Rollen definiert. Das Kernteam besteht aus
oberem und mittlerem Management, internem Projektleiter, evtl. externem Koordinator und ausgewählten
Mitarbeitern aus betroffenen Abteilungen. Das Kernteam muss sich auf die Projektdefinition, Projektplanung und Projektorganisation einigen und gegebenenfalls prozessspezifische Sub-Teams („BetaBenutzer“) einschließlich externen Partnern bilden.
566
Wie die Untersuchungen in der Praxis (Kapitel 4.2.2 und Kapitel 6.5.1) gezeigt haben ist dies
gerade für KMUs besonders wichtig, da oft keine schriftliche Strategie in diesem Bereich vorhanden
ist.
567
181
Methoden bzw. Werkzeuge (W):
W 1.1: [optional] Vorstudie
Die Vorstudie kann als quantitative Erhebung (ähnlich der explorativen Studie in Kapitel 4) oder qualitative Interviews (vgl. Experteninterviews W 2.4 in der Analysephase des Vorgehensmodells) ausgetragen
werden.
W 1.2: Vortrag
Ein Vortrag informiert über die Möglichkeiten der betrieblichen Integration auf unterschiedlichen Integrationsebenen. Die Durchführung sollte entsprechend der Unternehmenskultur mittels PowerpointPräsentation, Flipchart, oä. erfolgen.
Meilensteine (M):
M 1.1: Projektentscheidung
Entscheidung über Durchführung eines Projekts („Go-Entscheidung“). Die Entscheidung sollte vom
mittleren oder Top Management getroffen werden. Eine Unterstützung in weiterer Folge ist ein wichtiger
Erfolgsfaktor und sollte ebenfalls gegeben sein.
M 1.2: Projekt Kick-Off
Gemeinsames Kick-Off (2-3 Stunden), in dem das Gesamtprojekt der Projektgruppe vorgestellt und die
weitere Vorgehensweise zeitlich geplant wird.
Ergebnisse (E):
E 1.1: Integrationsstrategie
Die Integrationsstrategie des Unternehmens ist als Ergebnis der ersten Phase festzuhalten. Sie beinhaltet die Ausgangssituation, Vision, Auslöser und Ziele für die Integration.
E 1.2 [optional]: Vorstudie
Eine separate Dokumentation der Ergebnisse aus der Vorstudie ist durchzuführen.
E 1.3 [optional]: Kooperationsvertrag
Bei der Einbindung eines externen Koordinators mit entsprechender Methoden- und Durchführungskompetenz ist ein Kooperationsvertrag über den Inhalt und Umfang der Leistungen abzuschließen.
E1.4: Projektplan
Der Projektplan beinhaltet die konkrete Projektvorgehensweise und Projektziele, die sich aus der Integrationsstrategie ableiten und die weiteren Schritte im Projekt (ggf. aufgeteilt in mehreren Teilprojekten)
vorgeben.
7.3.2 Analyse (Phase 2)
In dieser Phase gilt es für das Unternehmen herauszufinden, welche Handlungsbedarfe zur betrieblichen Integration bestehen.
Je höher der Grad der Interaktion und Zusammenarbeit, desto wichtiger ist es, zu
verstehen, welche Prozesse und Methoden das Unternehmen derzeit einsetzt. Eine
umfassende Analyse wird daher als essenzieller Schritt erachtet, bevor die Aufmerksamkeit auf mögliche Werkzeuge zur Umsetzung gelenkt wird568. Es werden konkrete Lücken zwischen aktuellem Wissenslevel und existierenden Rahmenbedingungen
568
Vgl. Hain und Back (2011, S. 1)
182
und der in der Orientierungs-Phase definierten Integrationsstrategie (E1.1) transparent gemacht. Wichtig ist ein partizipatives Vorgehen, in der wiederum alle Stakeholder einbezogen werden. Mithilfe von qualitativen Methoden (Dokumentenanalyse,
Prozessanalyse, Semi-strukturiertes Experteninterview, Workshop) können Handlungsbedarfe in den Unternehmen identifiziert werden und mittels quantitativer Methoden (Erfolgsfaktorenanalyse) werden kritische Erfolgsfaktoren für die Handlungsbedarfe einer nachvollziehbaren Gewichtung unterzogen.
Als Startpunkt der Ist-Analyse (A2.1) bietet sich die Verwendung von schriftlichen
Ausarbeitungen aus verschiedenen internen Quellen wie die Dokumentation der
Struktur der Organisation, der Technik und des betrieblichen Umfeldes an. Sofern ein
Vorprojekt (A1.2) durchgeführt wurde, sollten Ergebnisse daraus ebenfalls in die
Analyse einfließen. Zu einer Identifikation und ersten Einschätzung relevanter Anspruchsgruppen gegenüber dem Projekt sollte eine Stakeholderanalyse durchgeführt
werden. Ein Stakeholder ist eine natürliche oder juristische Person, die entweder
potentiell durch das Projekt betroffen ist, oder potenzielle Auswirkungen auf das
Projekt hat. Jeder, der ein Interesse an dem Projekt hat, ist per Definition ein Stakeholder. Die Menge aller Beteiligten wird dabei nach der Art ihres Interesses in generische Gruppen zusammengefasst. Ein Stakeholder kann Mitglied mehrerer Gruppen
sein569. Es ist wichtig, jene Personen zu kennen, die ein begründetes Interesse an
dem Projekt haben. Vor allem diejenigen, die negativ betroffen sind oder skeptisch
sind, sollten identifiziert werden. Dies kann durch Wissen aus früheren Projekten,
persönlichen Kontakten und der Erfahrung der Promotoren erfolgen570. Das Ergebnis
kann in tabellarischer Form gelistet werden oder grafisch als Karte der Anspruchsgruppen („Stakeholder-Map“) ausgearbeitet werden571. Die Stakeholderanalyse deckt
oft widersprüchliche und gegensätzliche Positionen zwischen den Beteiligten auf572.
Damit stellt sie eine sinnvolle Maßnahme zur Sensibilisierung für Projekte mit mehreren Gruppen an Beteiligten dar und dient auch zur Vorbereitung auf anschließende
Workshops. Im Zuge der Analyse darf nicht auf den Bedarf externer Partner vergessen werden. Bei der Stakeholderanalyse sollten zu integrierenden Pilot-Partner
identifiziert werden. Wenn diese aufgrund räumlicher Distanz nicht direkt in Workshops eingebunden werden können, sollten die Anforderungen mittels telefonischer
oder online Befragung erhoben werden.
Für die weitere Erhebung und Dokumentation der Ist-Situation hat es sich in den
durchgeführten Pilotprojekten bewährt, die Erhebung mittels Workshops (A2.2) in
569
570
571
Vgl. Österle und Winter (2000, S. 75)
572
183
Kleingruppen (2 bis max. 4 Personen) zu unterstützen. Zur Herstellung einer nachzuvollziehenden Vollständigkeit der dargestellten Sachverhalte, empfiehlt die Literatur
die Verwendung von Petri-Netzen oder die Modellierung von ereignisgesteuerten
Prozessketten (EPK)573. Hierbei gilt es anzumerken, dass KMUs oft weder über die
nötigen Mittel verfügen, noch die Zeit haben, um eine detaillierte Analyse durchzuführen, sowie die Werkzeuge zur formalen Dokumentation fehlen. Um diesem Problem zu begegnen, können auch leicht handhabbare Techniken für die Analyse der
Handlungsbedarfe zur Anwendung kommen. In allen durchgeführten Pilotprojekten
wurden vordefinierte „Prozess-Karten“ für die Erhebung der Geschäftsprozesse in
Workshops verwendet. Es hat sich gezeigt, dass dies als Ausgangsbasis für semistrukturierte Interviews zweckdienlich und ausreichend ist, um ein gemeinsames
Fachverständnis über die Ist-Situation herzustellen. In den Interviews wird dann
vertiefend auf die Möglichkeiten der Kommunikation, Zusammenarbeit, Dokumentation, technologischen Unterstützung sowie Schwachstellen und Verbesserungen der
Ist-Situation eingegangen. Die Interviews sollten semi-strukturiert mit offenen Fragen
geführt werden574, wobei sich die Diskussion auf den skizzierten Prozess bezieht. Zu
Ende des Interviews werden die wesentlichen Ergebnisse kurz zusammengefasst
und die weitere Vorgehensweise besprochen. Es sollte auch auf den Zweck der
zusätzlichen Erfolgsfaktorenanalyse hingewiesen werden.
Als ergänzende, quantitative Erhebungsmethode hat sich die Erfolgsfaktorenanalyse (A2.3) in den Praxisprojekten bewährt. Die Erfolgsfaktorenanalyse „macht die
Mehrdimensionalität des Erfolgs bewusst und leitet eine systematische Diskussion
über erfolgsverbessernde Maßnahmen ein.“575 Sie ist eine Methode zur strategischen
Planung, die auf die Arbeiten von Alloway zurückgeht, der mittels Befragung einen
Katalog mit 26 Erfolgsfaktoren zur Messung des Erfolges in der Informationsverarbeitung entwickelte576. Die in der gegenständlichen Arbeit verwendete Vorgehensweise
basiert auf der von Lehner et al. ausgearbeiteten KnowMetrix577. KnowMetrix ist eine
Erfolgsfaktorenanalyse, die auf die Diagnose des Wissensmanagement eines Unternehmens spezialisiert ist. Wie auch bei dieser Methode vorgesehen, sind die Erfolgsfaktoren an die spezifischen Bedürfnisse der Unternehmen anzupassen und gezielt
abzufragen. Zur Datenerhebung kommt ein Fragebogen zum Einsatz, in dem für
jeden Faktor die aktuelle Ist-Situation (Leistung) im Unternehmen sowie die gewünschte Soll-Situation (Priorität) angegeben werden können. Das Ergebnis zeigt
573
Vgl. Thomas (2005, S. 22)
574
Vgl. Holtzblatt et al. (2010, S. 4665)
575
Heinrich (1999, S. 379)
576
Vgl. Alloway (1980)
577
Vgl. Lehner et al. (2009a)
184
eine praxistaugliche und fundierte Übersicht der Stärken und Schwächen578 und
liefert Ansatzpunkte für verbessernde Maßnahmen579.
Das wesentliche Ergebnis der Analysephase ist die ausgearbeitete Anforderungsspezifikation (E2.1), auch Lastenheft genannt. Das Dokument beschreibt, was die
geplante Integrationslösung leisten soll, und legt den grundlegenden weiteren Umsetzungsplan für das Projekt fest.
Nachfolgende Tabellen stellen die Aktivitäten, Methoden und Werkzeuge sowie
Meilensteine und Ergebnisse aus dieser Phase im Überblick dar.
Aktivitäten (A):
A 2.1: Ist-Analyse (Organisation, Technik, Umfeld)
Die Erfassung der Ist-Situation beinhaltet zunächst eine Erhebung aus organisatorischer (Struktur und
Aufbau der Organisation, Stakeholderanalyse), prozessorientierter (involvierte Geschäftsprozesse) und
technischer Sicht (vorhandene technische Infrastruktur und relevante Informationssysteme). Hier sind
sowohl die Anforderungen interner Stakeholder als auch der Bedarf des betrieblichen Umfeldes wie der
externen Partner (Pilot-Kunden, Pilot-Lieferanten,…) zu erheben, sofern diese im Projekt involviert sind.
Dadurch wird der Rahmen für das Projekt abgesteckt und dokumentiert.
A 2.2: Workshops durchführen
In den Workshops wird von den Teilnehmern je ein bestimmter, relevanter Prozess (aus den in A2.2
erhobenen, projektrelevanten Prozessen) durch individuelle Gewichtung (Punktevergabe) identifiziert und
der Prozess mit der höchsten Punkteanzahl ausgewählt. Dieser Prozess wird anschließend gemeinsam
erarbeitet und auf Prozesskarten modelliert. Danach wird in einem semi-strukturierten Interview die
Kommunikation, Dokumentation, Prozessunterstützung und Innovation im modellierten Prozess erhoben,
sowie Schwachpunkte und Verbesserungspotentiale identifiziert.
Die Stakeholderanalyse, welche im Rahmen der Ist-Analyse (A 2.2) durchgeführt wird, ist auch zur
Vorbereitung der Workshops relevant. So können relevante Workshop-Teilnehmer erkannt werden und
eine gezielte Vorbereitung auf mögliche Konflikte in den einzelnen Workshops ist möglich.
A 2.3: Erfolgsfaktorenanalyse durchführen
Diese zusätzliche Analyse dient zur Beurteilung der projektrelevanten Erfolgsfaktoren aus Sicht der
derzeitigen Ist-Situation. Es wird zum einen die aktuelle Leistung einzelner wichtiger Faktoren im Schulnotensystem bewertet. Zum anderen wird durch die Vergabe einer Priorität eine Gewichtung der Leistung
vorgenommen, dh. wie wichtig dieser Punkt aus Sicht der befragten Mitarbeiter eingeschätzt wird. Die
Erfolgsfaktoren werden dadurch in Abhängigkeit der ermittelten Ist-Leistung und Priorität abgebildet. Die
Mittelwerte dieser zwei Dimensionen gliedern die daraus resultierende Matrix in vier Felder oder Quadranten, wodurch Hinweise auf den Handlungsbedarf hinsichtlich der Erfolgsfaktoren sichtbar werden.
Jene Faktoren im Quadranten mit niedriger Leistung und hoher Priorität sind hinsichtlich Verbesserungsmaßnahmen primär zu adressieren, um die Leistung an die Priorität anzupassen.
578
579
Vgl. Lehner et al. (2009b)
Die Methodik der Durchführung der Erfolgsfaktorenanalyse sowie Ergebnisse werden im Detail in
Kapitel 8.2 bei Pilotprojekt 1 beschrieben.
185
W 2.1: Dokumentenanalyse und –auswertung
Verwendung von schriftlichen Ausarbeitungen aus verschiedenen internen Quellen (Überblick Organisation/Technik/Prozesse)
W 2.2: Stakeholderanalyse
Dient zur ersten Einschätzung relevanter Stakeholder gegenüber dem Projekt. Kann in tabellarischer
Form (mit den Spalten: Stakeholder, Interessen/Ziele, Vorwissen, positiver Einfluss, negativer Einfluss,
Projekt-Impact) erfolgen oder grafisch als Karte (Stakeholder-Map) ausgearbeitet werden. Durchführung
der Analyse mittels Tabellenkalkulationssoftware (z.B. Microsoft Excel, OpenOffice Calc,…).
W 2.3: Prozessanalyse
Skizzieren eines Prozesses über einfach gehaltene Prozesskarten. Es können vorgedruckte Kärtchen im
DIN A5 Format zum Festhalten des Titels, der Nummer, eines kurzen Inhalts des Prozess-Schrittes, der
involvierten Personen oder Rollen sowie der für den Schritt benötigten Daten bzw. Informationen verwendet werden. Der Ablauf des Prozesses soll auf 5 bis max. 8 Kärtchen festgehalten werden können.
Das erklärte Ziel ist nicht eine formal korrekte (EPK-)Modellierung, sondern ein allgemeines Verständnis
für das nachfolgende Interview herzustellen.
W 2.4: Semi-strukturierte Experteninterviews
Als Vorbereitung auf das Experteninterview ist ein Interviewleitfaden zu erstellen. Mithilfe des Leitfadens
kann das Interview strukturiert ablaufen, wesentliche Punkte werden während des Interviews direkt im
ausgedruckten Leitfaden notiert. Die zu stellenden Fragen sollten Themenbereiche wie die Kommunikation, Zusammenarbeit, Dokumentation (Dateiablage und –austausch, Wissensdokumentation, Medienbrüche, Wissensdokumentation, udgl.) und Innovation („Kreative neue Ideen und deren Umsetzung“) im
jeweiligen Prozess abdecken. Ferner sollen Schwachpunkte im Ist-Prozess und die Anforderungen an
den jeweils idealtypischen Soll-Prozess besprochen werden. Von dem Gespräch kann – nur nach
Rückfrage mit den Interviewteilnehmern – eine Audioaufzeichnung geführt werden.
W 2.5: Erfolgsfaktorenanalyse
Diese quantitative Erhebung kann mithilfe eines Online-Fragebogen (z.B. Befrager.de, Qualtrics.com)
oder auf Papier ausgegeben werden (je nach Unternehmenskultur). Zur grafischen Auswertung der
Fragebögen hat sich wiederum eine Tabellenkalkulationssoftware (z.B. Microsoft Excel, OpenOffice
Calc,…) bewährt.
Meilensteine (M):
M 2.1: Analyse abgeschlossen
Die wesentlichen Erkenntnisse aus der Analyse werden dem Top Management präsentiert und die
weitere Vorgehensweise detailliert.
Ergebnisse (E):
E 2.1: Anforderungsspezifikation („Lastenheft“)
Zusammengefasste Dokumentation der Ergebnisse aus der Analysephase in einem gemeinsamen
Analyse-Dokument (Verwendung eines Textverarbeitungsprogramms wie Microsoft Word oder OpenOffice Writer). Dieses Ergebnis ist dem Top Management vorzulegen und zu besprechen.
7.3.3 Design (Phase 3)
Nachdem in der Analysephase der Frage nachgegangen wurde: „Was soll umgesetzt
werden?“, befasst sich die Design-Phase nun mit dem „Wie?“. Das Ziel ist es, zu
spezifizieren, wie die in der Anforderungsspezifikation dokumentierten Handlungsbe-
186
darfe abgedeckt werden. Dabei werden die in der Analyse erhobenen funktionalen
und nichtfunktionalen Anforderungen und Verbesserungsvorschläge an die Organisation, Technik und Prozesse zu Anwendungsszenarien zusammengefasst und
konkrete Funktionalitäten für die Umsetzung zugeordnet. Beim Ableiten des Designs
der Anwendungsszenarien (A3.1) wird in folgenden Schritten vorgegangen:

Beschreibung des Designs in Hinblick auf die jeweilige Anforderung innerhalb
der Anwendungsszenarien sowie Szenarien übergreifend: Was muss durch
das System unterstützt bzw. ermöglicht werden, um die Anforderung erfüllen
zu können?

Beschreibung der Konzepte, Werkzeuge und Standards zur betrieblichen Integration, die den Bedarf des Designs decken können: Welche Funktionalität
einer Integrationslösung muss dazu gegeben sein? Als Entscheidungsunterstützung können die in der gegenständlichen Arbeit beschriebenen Fallstudien
und Pilotprojekte herangezogen werden. Beispielsweise können die Nutzung
von SaaS zum Drucken von elektronischen Rechnungen auf Prozess-Ebene,
die Verwendung von Wiki-Funktionalität zur gemeinsamen Dokumentation von
häufigen Kundenfragen auf der sozialen Ebene, oder die Unterstützung eines
EDIFACT-Standards zum Austausch von Rechnungen mit Lieferanten auf Datenebene erforderlich sein, um das Anwendungsszenario umzusetzen. Die
Frage nach den Werkzeugen hilft auch bei der Entwicklung und dem Aufbau
der benötigten Softwarearchitektur. Hier wird geklärt, ob die vorhandene Infrastruktur den Anforderungen genügt, ob zusätzliche Investitionen nötig sind,
oder ein Umstieg auf eine vollständig neue Infrastruktur erforderlich ist. Bei
Bedarf soll auch ein Partner für die Umsetzung des Entwurfs gefunden werden.

Aus Gründen einer späteren Nachvollziehbarkeit des Entwurfs ist es ratsam,
Referenzen auf den/die Workshop(s), aus dem/denen die jeweilige Anforderung stammt und die korrespondierenden Erfolgsfaktoren aus der Erfolgsfaktorenanalyse bei jeder Anforderung festzuhalten.

Zusätzlich ist anzugeben, um welche Art der Anforderung in Bezug auf die gesetzten Projektziele es sich handelt: Handelt es sich um eine Muss-, Soll-,
oder Kann-Anforderung?
Der Entwurfsprozess läuft inkrementell in mehreren Iterationen ab und involviert
wichtige Stakeholder über Feedback (A3.2). Die gebildeten Anwendungsszenarien
werden im Kernteam besprochen und priorisiert. Nach der Feedbackrunde ist das
187
Design gegebenenfalls zu adaptieren und erneut abzustimmen, bis ein gemeinsames
akkordiertes Design für Prototypentwicklung (A3.3) vorliegt580.
Aktivitäten (A):
A 3.1: Anwendungsszenarien entwerfen
Die in der Analyse identifizierten funktionalen und nichtfunktionalen Anforderungen und Verbesserungsvorschläge an die Organisation, Technik und Prozesse werden zu Anwendungsszenarien zusammengefasst und einer Umsetzung mittels Konzepten, Werkzeugen und Standards der betrieblichen Integration
zugeführt. Bei Bedarf soll ein Partner für die Phase der Realisierung gefunden werden.
A 3.2: Feedback einholen
Die identifizierten Anwendungsszenarien mit deren Umsetzung sind im Kernteam gemeinsam zu besprechen und zu priorisieren. Bei Bedarf können auch nochmals ausgewählte Workshop-Teilnehmer für eine
Detaillierung und Feedback herangezogen werden.
A 3.3: Design für Prototypentwicklung festlegen
Nach der Feedbackrunde ist das Design gegebenenfalls zu adaptieren und erneut abzustimmen, bis ein
gemeinsames akkordiertes Design-Ergebnis vorliegt.
W 3.1: Design
Für die Dokumentation des Entwurfs hat sich die Verwendung eines Tabellenkalkulationsprogramm (z.B.
Microsoft Excel, OpenOffice Calc,…) als praxistauglich erwiesen.
W 3.2: Fallstudien und Pilotprojekte zur Entscheidungsunterstützung
Erfolgreiche Umsetzungsbeispiele aus der Literatur, insbes. die in dieser Arbeit beschriebenen Fallstudien und Pilotprojekte, können als Best Practice herangezogen werden.
Meilensteine (M):
M 3.1: Design verfügbar
Ein abgestimmtes und abgenommenes Design-Dokument ist verfügbar.
Ergebnisse (E):
E 3.1: Design-Dokument
Dokumentation der Anwendungsszenarien aus der Designphase in einem gemeinsamen DesignDokument (z.B. Tabellarisch unter Verwendung von Microsoft Excel oder OpenOffice Calc), welches im
Kernteam beschlossen wurde.
580
Ein Beispiel des nach dieser Vorgehensweise erstellten Designs ist in Kapitel 8.2 bei Pilotprojekt 1
ersichtlich.
188
7.3.4 Realisierung (Phase 4)
Die vierte Phase umfasst die technische Implementierung der Integrationslösung auf
allen adressierten Ebenen. Die Tätigkeiten in dieser Phase sind von der gewählten
Integrationslösung abhängig und variieren dementsprechend stark. In der Praxis hat
sich gezeigt, dass oft ein externer Umsetzungspartner die Implementierung der
Integrationslösung systematisch durchführte. Auch die am Markt verfügbaren Werkzeuge stellen im Allgemeinen geeignete Dokumentationen und Beispiele zur Einführung und Anpassung zur Verfügung. Aus diesen Gründen ist die Implementierung
der Lösung selbst nicht Bestandteil des Vorgehensmodells. Ebenso wichtig wie die
physische Realisierung der Integrationslösung ist jedoch die methodische Begleitung
der Implementierung. Durch das Vorgehensmodell ist daher sicherzustellen, dass die
notwendigen Grundlagen für eine partizipative Umsetzung geschaffen und aufrechterhalten werden. Dazu hat es sich bewährt, dass die Implementierung in Form von
evolutionärem Prototyping bzw. Perpetual Beta (A4.1) durchgeführt wird. Der
konstruktiv-qualitative Entwicklungsansatz Prototyping ist eine Methode der Softwareentwicklung, die schnell zu ersten Ergebnissen führt und ein frühzeitiges Feedback bezüglich der Eignung des Lösungsansatzes erlaubt581. Evolutionäres Prototyping ermöglicht eine schrittweise Entwicklung der Integrationslösung über eine Folge
von lauffähigen Versionen582. Das Prinzip nie „fertig“ zu sein und dabei dauerhaft
benutzerzentriert weiterentwickelt zu werden, wird auch als Perpetual Beta bezeichnet. Auch wenn die Anforderungen sorgfältig erhoben wurden, ist es praktisch unmöglich, komplexe Lösungen in einem Schritt richtig umzusetzen. Außerdem kann
sich durch die Nutzung der Anwendung das organisatorische und soziale Gefüge der
Benutzer ändern, was eine erneute Anpassung bedingt583. Die einzelnen Anwendungsszenarien werden daher in kurzen Entwicklungszyklen realisiert und nach
erfolgreichem Test wird die Integrationslösung zur Benutzung freigegeben. Ein
Prototyp steht den Beta-Benutzern damit bereits frühzeitig (als dedizierte BetaVersion) zur Verfügung.
Vor der ersten Inbetriebnahme der Lösung sind die Anwender der Beta-Version
entsprechend ihres Vorwissens im Umgang mit dem Prototyp zu schulen (A4.2). Die
Benutzer können den Prototyp danach bereits produktiv einsetzen und daher auch
Feedback zum Umgang in ihrem Arbeitsumfeld geben.
Die Benutzer- und Systemdokumentation ist als Bestandteil einer nachhaltigen und
anpassungsfähigen Integrationslösung das Ergebnis der Entwicklungsphase (E4.1).
581
Vgl. Alavi (1984); Wilde und Hess (2007, S. 284)
582
Vgl. Sommerville (2001, S. 185ff)
583
Vgl. Koch und Richter (2009, S. 249)
189
Aktivitäten (A):
A 4.1: Prototyping („Perpetual Beta“)
Die einzelnen Anwendungsszenarien werden in kurzen Entwicklungszyklen in Form von evolutionärem
Prototyping bzw. Perpetual Beta realisiert und stehen den Anwendern daher bereits frühzeitig zur
Verfügung.
A 4.2: Schulung der Beta-Benutzer
Vor der ersten Inbetriebnahme der Plattform sind die ersten Anwendern (Beta-Benutzer) entsprechend
ihres Vorwissens im Umgang mit der Software zu schulen. Die Anwender sollen dabei den Prototyp
danach bereits produktiv in ihrem eigenen Arbeitsumfeld einsetzen können.
W 3.1: Perpetual Beta
Die Einführung der Anwendungsszenarien erfolgt methodisch in Form von evolutionärem Prototyping
bzw. Perpetual Beta. Dabei werden die einzelnen Anwendungsszenarien in kurzen Entwicklungszyklen
realisiert, getestet und stehen anschließend den Anwendern bereits frühzeitig (als Beta-Version) zur
Verfügung.
W 3.2: Schulungen
Die Schulungsmaßnahme stellt sicher, dass die Nutzung der Werkzeuge von allen (Beta-)Anwender
verstanden und vorgenommen wird. Die Schulung sollte in einem EDV-Labor erfolgen, da im Zuge der
Schulung über kurze Vorträge ein allgemeines Verständnis des Werkzeuges hergestellt und im LearningBy-Doing unmittelbar angewendet werden kann.
Meilensteine (M):
M 4.1: Beta-Prototyp verfügbar
Der erste Prototyp für einen eingeschränkten Benutzerkreis (Beta-Benutzer) ist verfügbar.
Ergebnisse (E):
E 4.1: Prototyp
Ein Prototyp wurde nach dem Prinzip des „Perpetual Beta” entwickelt und steht den Anwendern zur
Verfügung.
7.3.5 Betrieb (Phase 5)
Nach erfolgtem Rollout beginnt die produktive Nutzung der Integrationslösung bzw.
einzelner Werkzeuge für die Anwendungsszenarien. Zur Erfolgsmessung der Integrationslösung sieht das Vorgehensmodell vor, diese einer Evaluierung (A5.1) zu
unterziehen. Evaluierung meint „die zielbezogene Beurteilung von Evaluierungsobjekten auf der Grundlage eines Systems von Evaluierungskriterien“584. Diese Aktivität
584
Heinrich (1999, S. 432)
190
wurde explizit in das Vorgehen integriert, da die Evaluierung in der gängigen Praxis
oftmals vernachlässigt wird585. Für die kontinuierliche Verbesserung prototypischer
Implementierungen ist Feedback bzw. die Evaluierung des Beta-Produktes allgemein
unerlässlich. Die Evaluierung ist daher während der Realisierung durchzuführen und
soll dabei möglichst viele Anwender involvieren. Bei der Evaluierung ist eine Prüfung
funktionaler und nichtfunktionaler Anforderungen durchzuführen. Der Prototyp kann
als praktisch anwendbar betrachtet werden, wenn eine Übereinstimmung zwischen
den geplanten und den tatsächlich verfügbaren Funktionen und Leistungen besteht
und diese in Anspruch genommen werden. Bei Unstimmigkeiten bzw. Unzulänglichkeiten wird der Prototyp in mehreren Entwicklungszyklen weiter verfeinert und erweitert, bis eine Übereinstimmung erzielt wird. Für die Evaluierung werden eine heuristische Evaluierung, eine Eye-Tracking Analyse und die Verwendung eines Feedback
Blog vorgeschlagen:

Heuristische Evaluierung: Bei der heuristischen Evaluierung handelt es sich
um ein von Nielsen und Molich entwickeltes Verfahren zur Usability-Inspektion
nach allgemein anerkannten Prinzipien, den Heuristiken. Die Autoren haben
empirisch belegt, dass man mit fünf Gutachtern bis zu 90% der Usabilityprobleme findet586. Damit gilt dieses expertenorientierte Evaluierungsverfahren als
einfach anzuwendend und kostengünstig und ist in der Praxis häufig zur Evaluierung von frühen Prototypen anzutreffen587. Wenn mehrere Gutachter eingesetzt werden, sollten sich diese zuvor abstimmen, um validere Ergebnisse
zu erhalten588. Neben den von Nielsen und Molich beschriebenen Heuristiken,
bieten sich die sieben Grundsätze der Dialoggestaltung nach DIN EN ISO
9241 Teil 110 zur Usability-Evaluierung an589. Die Methode setzt die Verfügbarkeit von Usability-Experten voraus, welche die Heuristiken kennen und korrekt interpretieren können. Diese sind in Praxisprojekten oft nicht anzutreffen.
Um den Mangel an Usability Know-How zu kompensieren, hat sich die heuristische Evaluierung in einer geführten Interview-Situation als praxistaugliche
Methode herausgestellt. Ein Experte führt mehrere Usability-Evaluierungen mit
585
In Kapitel 6 wurde gezeigt, dass Investitionen in die IT in der Praxis oft unvollständig oder gar nicht
evaluiert werden, da ein Mangel an anwendbaren Methoden und Werkzeugen besteht.
586
Vgl. Nielsen und Molich (1990, S. 255)
587
Vgl. Hollingsed und Novick (2007, S. 249–250)
588
Vgl. Petrie und Buykx (2010)
589
Die sieben Heuristiken lauten: Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Steuerbarkeit, Erwartungskonformität, Fehlertoleranz, Individualisierbarkeit und Lernförderlichkeit. Vgl. ISO
9241-110:2006
191
jeweils einem Beta-Benutzer und notiert die Probleme hinsichtlich der zu untersuchenden Heuristiken590.

Eye-Tracking Analyse: Die Blickaufzeichnung dient als zusätzliche Möglichkeit der Evaluierung von visuellen und interaktiven Elementen der Integrationslösung591. Eye-Tracking hilft nicht nur bei der Verbesserung der Usability,
sondern zeigt auch das affektive Verhalten von Benutzern beim Blick auf das
System592. Anhand von Scan-Pfaden zeigen Eye-Tracking Ergebnisse, wie
strukturiert oder unstrukturiert ein Proband den Weg zu einem gesuchten Bereich mit den Augen zurücklegt. Dieser Pfad besteht aus einer Abfolge von fixierten Punkten („Fixationen“) und den zwischen diesen Punkten liegenden
Strecken oder Sprünge („Sakkaden“). Die Verdichtung dieser Informationen
von mehreren Probanden nennt man Heatmaps. Die Durchführung einer EyeTracking Studie ist durch die zusätzliche Involvierung der Nutzer eine weitere
Möglichkeit zur Partizipation und trägt positiv im Sinne des Projektmarketing
bei593.

Feedback Blog: Ergänzend ist die Verwendung eines Blogs als Feedbackkanal sinnvoll. Der direkte Austausch von Meinungen, die Einbringung von Verbesserungsvorschlägen und die Meldung von Fehlern stellen einen ungezwungenen Dialog zwischen Beta-Benutzer und Entwickler her. In der Literatur konnte bereits gezeigt werden, dass Konzepte wie Blogs ein besonderes
Potential besitzen, Stakeholder zu involvieren594. Auch in den Pilotprojekten
zeigte sich, dass der Einsatz eines Blogs als Rückmeldungs- und Kommunikationskanal zur guten Nutzung des Systems beitragen kann595. Idealerweise ist
der Feedback Blog in die Integrationslösung integriert, sodass bei Verwendung des Blogs gleichzeitig auch die Integrationslösung genutzt wird. So
spricht der Blog das Ansehen und die intrinsische Motivation der Nutzer an
und fördert die aktive Teilnahme an der Integrationslösung.
Der kombinierte Einsatz mehrerer Methoden bei der Evaluierung bietet zusätzlich
den Vorteil, dass dabei Mängel und Fehler aufgedeckt werden, die mit einer Methode
alleine nicht gefunden werden würden596. Weiters unterstreicht diese Evaluierungs-
590
Siehe Beschreibung der Vorgehensweise bei der heuristischen Evaluierung in Pilotprojekt 1
(Kapitel 8.2)
591
Vgl. Duchowski (2007); Djamasbi et al. (2010)
592
Vgl. Herendy (2009, S. 287); Jacob und Karn (2003)
593
Die Ergebnisse einer Eye-Tracking Studie sind bei Pilotprojekt 1 ersichtlich (Kapitel 8.2).
594
Vgl. Stocker et al. (2008, S. 589)
595
Sowohl in Pilotprojekt 1 (Kapitel 8.2) als auch in Pilotprojekt 3 (Kapitel 8.4) wurde während der
Beta-Phase des Projektes ein Feedback Blog integriert.
596
Cyr et al. (2009, S. 554)
192
kombination den partizipativen Charakter durch Involvierung möglichst aller Anwender erneut. Die Ergebnisse der Evaluierung dienen zur Verbesserung des Prototyps
und fließen daher sofort in die Weiterentwicklung mit ein. Ziel ist es, durch die aktive
Involvierung und Einbindung in die tägliche Arbeit, „Quick Wins“ zu erzeugen. Die
Adaptierung der Tools vollzieht sich in mehreren Zyklen aus Implementierung, gegebenenfalls erneute Schulung597 und Evaluierung (z.B. Feedback von Nutzern über
Blog).
Ziel der Phase ist es, dass für die entwickelten Werkzeuge vom internen Projektleiter
eine formelle Abnahme (A5.2) erfolgt, diese damit in den regulären Betrieb übernommen werden und in der Folge innerhalb des Unternehmens ein kontinuierlicher
Verbesserungsprozess (A5.4) angestoßen wird. Dies ist aufgrund der laufenden
Veränderungen innerhalb eines Unternehmens und seiner Umwelt notwendig. Um
dieses Ziel zu erreichen, müssen zusätzlich zur Schulung von Endbenutzern auch
die System- und Plattform-Administratoren geschult (A5.3) werden. Ein Evaluierungsbericht (E5.1) dokumentiert den Erfolg (oder Misserfolg) der Integrationslösung.
Der Bericht ist im Kernteam zu besprechen und auch dem Top Management vorzulegen. Die Evaluierung sollte periodisch durchgeführt werden und so einen Prozess
der kontinuierlichen Verbesserung anstoßen. Das Einbringen von Verbesserungsvorschlägen seitens der Partner kann über persönliche Treffen (Partnertreffen, Meetings, Schulungen, Trainings, „Stammtischrunde“)598 oder online über einen Projekt
Blog599 mit Veröffentlichung von Neuerungen und Möglichkeit zur Kommentierung
und Bewertung erfolgen.
Aktivitäten (A):
A 5.1: Evaluierung durchführen
Eine mehrfache Evaluierung ist für die kontinuierliche Verbesserung von Prototypen wichtig und wird
deshalb bereits während der frühen Beta-Phase der Realisierung begonnen. Der kombinierte Einsatz
mehrerer Methoden bei der Evaluierung bietet den Vorteil, dass dabei Mängel und Fehler aufgedeckt
werden, die mit einer Methode alleine nicht gefunden werden würden. Auch unterstreichen Evaluierungsmethoden wie die heuristische Evaluierung, Eye-Tracking Analyse und Verwendung eines Feedback Blog den partizipativen Charakter durch Involvierung der Anwender.
A 5.2: Abnahme
Für die Übernahme von entwickelten Beta-Werkzeugen in den regulären Betrieb ist eine offizielle Ab-
597
Zumindest sollten den Beta-Benutzern Informationen über neue, verbesserte, oder geänderte
Funktionalitäten zukommen.
598
In Fallstudie 1 werden im Rahmen des KVP quartalsweise Partnertreffen und persönliche Beratungen durchgeführt (vgl. Kapitel 6.2)
599
Im Pilotprojekt 1 werden über den „Intranet T2.0 Blog“ aktuelle Neuigkeiten zum Projekt an die
Endnutzer kommuniziert (vgl. Kapitel 8.2).
193
nahme des Werkzeuges durch den internen Projektleiter notwendig. Danach steht das Werkzeug für das
Anwendungsszenario allen notwendigen Benutzern zur Verfügung.
A 5.3: Schulung Administratoren und Endbenutzer
Die Schulung von Endbenutzern aber auch von Administratoren (System-und Plattform-Administratoren)
ist wesentlich für die Akzeptanz des Systems. Hierbei sollte wiederum der Nutzen der Stakeholder (dh.
der Person, die das Werkzeug für die täglichen Arbeitsprozesse benötigt) in den Vordergrund gestellt
werden.
A 5.4: Kontinuierliche Verbesserung
Aufgrund von laufenden organisatorischer, technischer und kultureller Veränderungen innerhalb des
Unternehmens und seiner Umwelt ist ein kontinuierlicher Verbesserungsprozess (KVP) unerlässlich. Dies
sollte durch die Einbindung der Anwender über einen Projekt-Blog (dh. die Veröffentlichung von Neuerungen und Möglichkeit zur Kommentierung und Bewertung), durch die Sammlung, Bewertung und
Umsetzung von neuen Ideen, über persönliche Key-Nutzer Treffen etc. erfolgen.
W 5.1: Abnahmeprotokoll
Das offizielle Protokoll über die Abnahme der einzelnen Werkzeuge der Lösung kann als tabellarische
Aufstellung mit einem Textverarbeitungsprogramm (z.B. Microsoft Word, OpenOffice Writer,…) oder
einer Tabellenkalkulationssoftware (z.B. Microsoft Excel, OpenOffice Calc,…) erstellt werden. Das
Protokoll wird vom Projektleiter unterschrieben.
W 5.2: Schulungen
Die Schulungsmaßnahme stellt sicher, dass die Nutzung der Werkzeuge von allen Endbenutzern aber
auch von Administratoren (System-und Plattform-Administratoren) verstanden wird. Die Schulung sollte
in einem EDV-Labor erfolgen, da im Zuge der Schulung über kurze Vorträge ein allgemeines Verständnis
des Werkzeuges hergestellt und im Learning-By-Doing unmittelbar angewendet wird. Administratoren
werden zusätzlich in der Wartung der Werkzeuge geschult.
W 5.3: Evaluierungsmethoden
Methoden zur Evaluierung von Software sind die heuristische Evaluierung, Eye-Tracking Analyse und die
Verwendung eines Feedback Blog.
Meilensteine (M):
M 5.1: Abnahme erfolgt
Die formale Abnahme mittels Abnahmeprotokoll ist erfolgt.
Ergebnisse (E):
E 5.1: Evaluierungsbericht
Ein Evaluierungsbericht fasst die Ergebnisse der Evaluierung zusammen.
E 5.2: Produktiv einsetzbare Werkzeuge
Ergebnis der Phase sind die im Arbeitsalltag produktiv einsetzbaren Werkzeuge.
7.4 Zusammenfassung
In diesem Kapitel wurde ein Überblick über das konsolidierte Vorgehensmodell
gegeben, das Rollenmodell vorgestellt und eine Zusammenfassung der einzelnen
194
Phasen gegeben. Die für eine Durchführung betrieblicher Integration notwendigen
Aktivitäten und Ergebnisse müssen von geeigneten Methoden unterstützt werden.
Spezielle partizipative Methoden wurden über Pilotprojekte praktisch erprobt und sind
nach deren Abschluss in das konsolidierte Vorgehensmodell zurückgeflossen. Das in
diesem Kapitel beschriebene Vorgehensmodell stellt daher eine aus Wissenschaft
und Wirtschaft konsolidierte Vorgehensweise bei der betrieblichen Integration dar.
Die wissenschaftliche Fragestellung (FS5) wurde damit beantwortet. Zusammenfassend werden das entwickelte Vorgehensmodell in den Gestaltungsstrategien der
Systementwicklung eingeordnet sowie die definierten Anforderungen an das Vorgehensmodell diskutiert.
Tabelle 12 enthält die Einordnung des Vorgehensmodells nach den Gestaltungsstrategien der Systementwicklung. Eine eingefärbte Spalte kennzeichnet eine Zuordnung
des Modells zur jeweiligen Strategie.
Tabelle 12: Einordnung des Vorgehensmodells nach Gestaltungsstrategien der Systementwicklung600
Nach Anzahl der Gestaltungsstufen
Nach der Verwendungshäufigkeit
Nach Systemkonzept
Nach Umweltbezug
Nach Richtung
Nach Ausgangspunkt
Nach Schwierigkeitsgrad
Einmalig
Iterativ oder schrittweise
Einfachverwendung
Mehrfachverwendung
Datenorientiert
Inside-Out
Funktionsorientiert (an Abläufen)
Outside-In (Rahmenbedingungen
der Systemumwelt ausgehend)
Top-Down
Meet-in-the-Middle
Bottom-Up
Induktiv (Ist-Zustandsorientiert) Deduktiv (Soll-Zustandsorientiert)
Easiest-first
Hardest-first
Das Vorgehensmodell versteht sich als iterativ-evolutionäres Phasenmodell, da
sich einzelne Phasen überlappen können und das Endprodukt in mehreren prototypischen Entwicklungszyklen erstellt wird. Das Vorgehensmodell kann mehrfach verwendet werden und es orientiert sich dabei an bestehenden Geschäftsprozessen,
dh. es wird ein funktionsorientiertes Systemkonzept verfolgt. Die Integrationsdimensionen Technologie, Organisation und betriebliches Umfeld sind zu berücksichtigen, weshalb es dem Outside-In Ansatz zuzuordnen ist.
Betrachtet man die Richtung der Systementwicklung, so kann ein Top-DownVorgehen bei Neuentwicklungen sinnvoll sein, was jedoch auch hier nicht zwingend
ist. Selten kann allerdings auf der „grünen Wiese“ begonnen werden. Bei existierenden Anwendungen bzw. historisch gewachsenen Lösungen ist ein Bottom-Up oder
Meet-in-the-Middle Ansatz zielführender601. Eines der Probleme dieser unterschied600
Vgl. Tabelle 9, in Anlehnung an Schwarze (2000, S. 162)
601
195
lichen Entwicklungsmöglichkeiten ist, dass sie nicht eindeutig klären, mit welchen
Geschäftsprozessen ein Unternehmen beginnen soll und wie diese zu Anwendungsszenarien kombiniert werden sollen602. Selbst in sehr einfachen Fällen ist meist ein
Meet-in-the-Middle Ansatz einem Top-down Vorgehen vorzuziehen, da jedes bestehende System in der Realität die Rahmenbedingungen und Modellierungsentscheidungen einschränkt603. Das Vorgehensmodell beginnt die Analyse daher auch mit
der aktuellen Ist-Situation (Ist-Zustandsorientiert). Anforderungen an einen SollZustand sind ebenso wichtig, weshalb in der Analysephase auch Schwachpunkte
und Verbesserungspotentiale an Soll-Prozesse und Soll-Leistungen zu identifizieren
sind.
Vom Schwierigkeitsgrad her wird ein Easiest-first Ansatz bevorzugt, da über prozess- bzw. anlassbezogene „Quick-Wins“ rasch Erfolge erzielt und so die Akzeptanz
gesteigert werden kann. Eine ganzheitliche Analyse im Unternehmen, um möglichst
alle Potentiale für eine Reihe von Anwendungsszenarien zu erkennen und nachfolgend gewinnbringend für das Unternehmen nutzen zu können, stellt einen wesentlichen Grundstein für den Erfolg im Projekt dar. Bei der Priorisierung der Umsetzung
einzelner Anwendungsszenarien sollte demnach der Easiest-first Ansatz Berücksichtigung finden. Aber auch die Integration in bestehende Arbeitsprozesse sowie das
Erreichen einer kritischen Anwendermasse durch den Einsatz geeigneter partizipativer Methoden sind wichtige Bausteine. Durch die abteilungsübergreifende Involvierung betroffener Mitarbeiter in einem partizipativen und damit für alle Beteiligten
transparenten Vorgehen kann dies erzielt werden604. Um den Willen und die Unterstützung der (zukünftigen) Benutzer zu stärken, stehen der zu unterstützende Prozess und die involvierten Aufgabenstellungen und deren Partizipanten im Vordergrund605. Technische Systeme und Belange rücken in den Hintergrund, was deren
benutzungsfreundliches und prozessadäquates Funktionieren zur Unterstützung von
Kultur und Prozessen voraussetzt.
Zusätzlich zur Einordnung des Vorgehensmodells werden an dieser Stelle noch die
an das Vorgehensmodell gestellten Anforderungen aufgegriffen606. Aus Sicht der
definierten Anforderungen lässt sich feststellen:

Das gesamte Integrationsprojekt wurde in einzelne konkrete Aktivitäten
aufgeteilt. Die allgemeine Anforderung (AllgA-1) „Eine Gliederung der Ge-
602
Vgl. Papazoglou und van Den Heuvel (2006, S. 423)
603
Vgl. Zimmermann et al. (2005, S. 5)
604
Vgl. Koch und Richter (2009, S. 167); Stocker et al. (2008, S. 589)
605
Vgl. Chui et al. (2009)
606
Siehe Kapitel 5.5.
196
samtaufgabe in einzelne Schritte (dh. Aktivitäten) ist vorzunehmen.“ gilt damit
als erfüllt.

Die Aktivitäten wurden in fünf Phasen gruppiert und in einen logischen Ablauf gebracht. Die Phasen Orientierung, Analyse, Design, Realisierung und
Betrieb wurden konsistent in der Literatur identifiziert und decken den gesamten Integrationsprozess ab. Damit wurde die Anforderung „AllgA-2“ erfüllt.

In jeder Phase wurden einzelne anwendbare Methoden und Werkzeuge
zugeordnet. Die Methoden und Werkzeuge wurden in Praxisprojekten auf deren Anwendbarkeit im Anwendungskontext geprüft. Zusätzlich wurde ein Rollenmodell definiert und die Rollen auf der Basis einer RACI-Matrix den einzelnen Aktivitäten zugeordnet. Die Anforderung „AllgA-3“ wurde damit abgedeckt.

Durch die Definition der zentralen Ergebnisse jeder Phase wurde die Anforderung „AllgA-4“ erfüllt. Diese werden in einer oder mehreren Aktivitäten sukzessive produziert. Ein Ergebnis kann bzw. soll daher auch als Input für eine
nachfolgende Aktivität fungieren.

Bereits mehrfach wurde die Anforderung der Strategieorientierung („SpezA-1“)
angesprochen: In der ersten Phase, der Orientierung, wird deshalb explizit eine Integrationsstrategie abgeleitet, welche die Ziele für das Projektvorhaben vorgibt.

Spezielles Augenmerk wurde auf die Inkludierung einer möglichst ganzheitlichen Analyse unter Berücksichtigung der drei Integrationsdimensionen
gelegt („SpezA-2“). Die Analysephase beinhaltet die technische Dimension,
indem die vorhandene technische Infrastruktur und relevante Informationssysteme einbezogen werden. Auf die Struktur und den Aufbau der Organisation,
sowie auf die Anforderungen interner Personen wird ebenso geblickt wie auf
das betriebliche Umfeld.

In allen Phasen wurde auf die Involvierung wichtiger Stakeholder durch
die Anwendung geeigneter Methoden geachtet. Dies fördert eine partizipative Vorgehensweise und deckt die Anforderung „SpezA-3“ ab.

Die Verwendung von Fallstudien zur Konstruktion sowie die Anwendung des
Vorgehensmodells in der Praxis haben gezeigt, dass das Vorgehensmodell
die vielfältigen Möglichkeiten und Konzepte der betrieblichen Integration
auf unterschiedlichen Integrationsebenen unterstützt. Es konnte gezeigt
werden, dass eine Integration auf Ebene der Daten und auf Ebene der betrieblichen Informationssysteme, ein Einsatz von Middleware zur Integration, eine
Integration auf sozialer Ebene sowie eine Integration auf Ebene der Prozesse
sinnvoll und möglich sind. Die Anforderung „SpezA-4“ kann daher durch die
Anwendung des Vorgehensmodells umgesetzt werden.
197

Die Realisierung der Integrationslösung wird im Vorgehensmodell mittels
„Perpetual Beta“ vorgenommen. Die Anwendung in den Pilotprojekten hat gezeigt, dass die evolutionäre Entwicklung mittels Prototyping rasch vorzeigbare Ergebnisse liefert und man auf Feedback schnell reagieren kann. Die
definierte Anforderung „SpezA-5“ gilt dadurch als erfüllt.

Die letzte Anforderung adressiert die Anwendbarkeit des Vorgehensmodells in
der Unternehmenspraxis („SpezA-6“). Die praktische Anwendbarkeit wurde
durch die Durchführung von drei Pilotprojekten sichergestellt. Die Pilotprojekte werden im nächsten Kapitel besprochen.
198
Anwendung des Vorgehensmodells in der Praxis
8 Anwendung des Vorgehensmodells in
der Praxis
Zur Detaillierung und Erprobung einzelner Methoden und Werkzeuge in gängiger
Unternehmenspraxis wurden drei Pilotprojekte mit den Unternehmen Teufelberger,
NKE und Fronius durchgeführt. Das Ziel aus wissenschaftlicher Sicht war es, die
betrieblichen Integrationsvorhaben methodisch zu begleiten und damit das Vorgehensmodell zu evaluieren. Es wird dadurch die wissenschaftliche Fragestellung
(FS6) beantwortet: Wie kann das Vorgehensmodell auf dessen praktische Anwendbarkeit im inner-, über- und zwischenbetrieblichen Kontext erprobt werden?607
Wie in Abbildung 55 ersichtlich, beginnt das Kapitel mit einem Überblick über die
Pilotprojekte (Kapitel 8.1). Daran anschließend wird die Vorgehensweise bei der
Einführung der Integrationslösung in den drei Projekten im Detail beschrieben. Kapitel 8.2 beschreibt das Pilotprojekt mit Teufelberger, Kapitel 8.3 das Pilotprojekt mit
NKE und in Kapitel 8.4 wird auf das Pilotprojekt mit Fronius eingegangen. Kapitel 8.5
enthält eine Zusammenfassung.
607
199
8.1 Überblick über Pilotprojekte
Das jeweilige inhaltliche Ziel der Projekte war eine Integrationslösung in Form einer
webbasierten Plattform aufzubauen. Dabei wurden je nach Fokussierung verschiedene Integrationsebenen adressiert und mehrere Anwendungsszenarien umgesetzt.
Pilotprojekt 1 behandelt die Umsetzung des Projektes „Intranet T2.0“ innerhalb des
Unternehmens Teufelberger GmbH zur abteilungs- und standortübergreifenden
Unterstützung informationsund wissensintensiver Bereiche (Kapitel 8.2). Die Einführung einer Integrationslösung zum zwischenbetrieblichen Informationsaustausch mit
Kunden und Lieferanten bei der NKE Austria GmbH ist Gegenstand von Pilotprojekt
2 (Kapitel 8.3). In Pilotprojekt 3 wurden standortübergreifenden Innovationsnetzwerken zur Zusammenarbeit bei Fronius International GmbH umgesetzt (Kapitel 8.4).
Tabelle 13 fasst die Eckdaten der Pilotprojekte zusammen. Die Tabelle zeigt auch
die durchgeführten Aktivitäten und Methodenanwendung in den Projektphasen. Alle
drei Pilotprojekte wurden methodisch von der FH Steyr begleitet, im Pilotprojekt 2
wurde ein zusätzlicher Umsetzungspartner eingebunden. Die Tabelle zeigt auch die
wesentlichen Aktivitäten und Methoden bei der Umsetzung im Überblick.
Tabelle 13: Eckdaten der Pilotprojekte
Beteiligte Unternehmen
Begleitung bei der
Durchführung
Projektleiter seitens
Unternehmen (Abteilung)
Externer Koordinator
Projektmitarbeit
Pilotprojekt 1
Pilotprojekt 2
Pilotprojekt 3
Teufelberger GmbH
NKE Austria GmbH
01/2010 – 01/2011
12/2009 – 05/2011
Fronius International
GmbH
07/2011 – 05/2012
Herwig Kirchberger
(Business Development)
Andreas Auinger (FH
Steyr)
Dietmar Nedbal (FH
Steyr)
Veronika Krempl
(Projektmanagement)
Gerald Aigner (Innovation Manager)
Andreas Auinger (FH
Steyr)
Alexander Hochmeier
(FH Steyr), Dietmar
Nedbal (FH Steyr)
FH Steyr, zusätzlicher
Partner (anonym)
Integrationsstrategie,
Projektdefinition &
Kick-Off
Dietmar Nedbal (FH
Steyr)
Andreas Auinger (FH
Steyr), Alexander
Hochmeier (FH Steyr)
FH Steyr
Umsetzungspartner
FH Steyr
Phase Orientierung
Vorstudie, Vorstellung
der Potentiale, Projektdefinition & KickOff
Stakeholderanalyse,
Erfolgsfaktorenanalyse, Prozessanalyse,
Workshops mit
Experteninterviews
Phase Analyse
Stakeholderanalyse,
Prozessanalyse,
Workshops mit
Experteninterviews
Vorstudie, Vorstellung
der Potentiale,
Projektdefinition &
Kick-Off
Prozessanalyse,
Workshops mit
Experteninterviews,
Erfolgsfaktorenanalyse
200
Phase Design
Phase Realisierung
Phase Betrieb
Pilotprojekt 1
Pilotprojekt 2
Pilotprojekt 3
Feinspezifikation,
Bewertung & Priorisierung, Auswahl der
Lösung
“Perpetual Beta”
Implementierung,
Schulung der BetaBenutzer
Heuristische Evaluierung, Eye-Tracking
Evaluierung, Feedback
Blog, Abnahme,
Schulung der Administratoren, Kontinuierliche Verbesserung
(laufend)
Feinspezifikation,
Lösung
Implementierung,
Heuristische Evaluierung, Abnahme,
Schulung der Administratoren, Kontinuierliche Verbesserung
(laufend)
Feinspezifikation,
Lösung
Implementierung,
Heuristische Evaluierung, Feedback Blog,
Abnahme, Schulung
der Administratoren,
Kontinuierliche Verbesserung (laufend)
Die Pilotprojekte werden in der weiteren Folge diskutiert. Der Fokus liegt auf der
Beschreibung der Vorgehensweise, wobei nicht alle angewendeten Methoden in
jeder Fallstudie gezeigt werden, da kein zusätzlicher Erkenntnisgewinn aus der
mehrfachen Ausführung erzielt werden kann.
8.2 Pilotprojekt 1: Standortübergreifende Integration bei Teufelberger
Dieses Kapitel skizziert die Umsetzung des Projektes „Intranet Teufelberger 2.0“ oder
kurz „Intranet T2.0“ innerhalb des Unternehmens Teufelberger GmbH zur Unterstützung informationsund wissensintensiver Bereiche. Die Dokumentation ist auch als
Fallstudie in einer kürzeren Fassung als Buchbeitrag erschienen608. Die Fallstudie ist
darüber hinaus in einer Langfassung auf der Webseite zu Enterprise 2.0 Fallstudien609 zum Download verfügbar.
8.2.1 Unternehmensdarstellung
Das Unternehmen. Die Teufelberger GmbH mit Hauptsitz in Wels wurde 1790
gegründet und ist ein österreichischer Produzent von Stahlseilen, Faserseilen sowie
von Umreifungsbändern, Erntegarnen und Faserverbundstoffen. Mit 750 Mitarbeitern
an 5 Produktionsstandorten in Österreich (Teufelberger GmbH in Wels, Teufelberger
Seil GmbH in Wels, Teufelberger Seil GmbH in St. Ägyd), Tschechien (Jihotex spol
608
609
Vgl. Auinger et al. (2012)
URL:
http://www.e20cases.org/fallstudie/teufelberger-intranet-t2-0-einf%C3%BChrung-undumsetzung/, Teufelberger Intranet T2.0: Einführung und Umsetzung [12.01.2013]
201
s.r.o. in Veselí nad Lužnicí) und den USA (New England Ropes in Fall River) wurde
2010 ein Jahresumsatz von 144 Mio. Euro erwirtschaftet. Teufelberger exportiert
mehr als 90% seiner Produkte und bedient damit eine Vielzahl von Märkten weltweit.
Die zwei wichtigsten und somit auch für das vorliegende Projekt relevanten Konzernsprachen sind Englisch und Deutsch.
Organisatorisch ist das Unternehmen in die drei strategischen Geschäftsbereiche
Wire Rope, Fiber Rope und Fiber & Plastics unterteilt: Im Geschäftsbereich Wire
Rope werden Stahlseile für Seilbahnen, Krane, den Bau, die Industrie, für Pistenwinden sowie für Produkte zur Personenabsturzsicherung hergestellt. Unter den zweiten
Geschäftsbereich Fiber Rope fallen Faserseile für verschiedenste Anwendungsszenarien. Einsatz finden diese bspw. in der Forstwirtschaft, dem Boots- und Klettersport, der Baumpflege sowie für Faserverbund Anbindungen und der Faserverbundgeflechte. Im dritten Geschäftsbereich Fiber & Plastics werden Umreifungsbänder
aus Polyester und Polypropylen sowie Erntegarne hergestellt und vertrieben. Eingesetzt werden diese Produkte vor allem in der Baustoff- und Holzindustrie, der Dosen-,
Flaschen- und Ballenindustrie sowie als Erntebindegarne zur Strohbergung.
Vision. Die Vision des Projektes „Intranet T2.0“ ist die Konzeption und Umsetzung
einer webbasierten Kommunikations- und Kollaborationsdrehscheibe, in der von
berechtigten Personen relevante Informationen aufgefunden, eingesehen, verlinkt,
kommentiert, kategorisiert und visualisiert werden können und kontextbezogene
Zusammenarbeit stattfindet. Teufelberger legt großen Wert auf Vernetzung: So sind
nicht nur die drei Geschäftsbereiche untereinander vernetzt, sondern es gibt auch
nach außen hin definierte Schnittstellen zu Lieferanten, Kunden, Systemherstellern
und Forschungseinrichtungen. Das Projekt Intranet T2.0 liefert vor allem zum Vernetzungsgedanken und somit auch zur Vision des Unternehmens als Ganzes einen
wesentlichen Beitrag.
Stellenwert von IT und Integrationstechnologien. Obwohl es sich bei Teufelberger
um ein klassisches Produktionsunternehmen handelt, nimmt die IT einen hohen
Stellenwert ein. Neben bewährten betrieblichen Informationssystemen wie bspw.
SAP für die Produktionsplanung und -steuerung, werden zahlreiche weitere Werkzeuge und Systeme eingesetzt. Ein Beispiel dafür ist das bestehende Intranet: Neben typischen Intranet-Inhalten wie internen Aushängen oder Mitarbeiterzeitungen
gibt es hier auch erweiterte Funktionalitäten, etwa in den Bereichen Wissensmanagement und Ideen-Management. Hervorzuheben ist hier die softwaregestützte
Lösung TIM („Teufelberger Ideen Management“). Hier können Mitarbeiter konkretere
Verbesserungsvorschläge und Ideen samt erwartetem Nutzen dokumentieren und
verschiedenen Verbesserungsbereichen zuteilen. Die Geschäftsleitung oder jeweilige Teamleitung bewertet die Ideen und bringt diese gegebenenfalls zur Umsetzung.
202
Integrationsbedarf. Im Rahmen einer bei Teufelberger intern durchgeführten Vorstudie („ePresence“) fand man über einen Fragebogen heraus, dass alle drei Geschäftsbereiche grundsätzlich gegenüber dem Einsatz von neuen Medien aufgeschlossen sind. Vor allem Verbesserungen in den Bereichen interne und externe
Kommunikation, Beschleunigung von Entscheidungsfindungen, Förderung von
kreativen Arbeitsstrukturen und im Bereich Wissensmanagement werden von den
befragten Personen gewünscht.
8.2.2 Vorgehensweise bei der Projektabwicklung
Für die Projektabwicklung zur Erfüllung der Projektvision wurde gemäß des Vorgehensmodells in den Phasen Orientierung, Analyse, Design, Realisierung, und Betrieb
vorgegangen. Die nachfolgenden Kapitel beinhalten eine Zusammenfassung der in
den Phasen durchgeführten Tätigkeiten und eine Beschreibung ausgewählter Methoden.
8.2.2.1 Orientierung
Der Integrationsbedarf war gegeben und wurde zusätzlich mit einer eigenen Vorstudie belegt. Die Ergebnisse dieser Studie wurden der Geschäftsführung präsentiert.
Mit diesen ersten Ergebnissen wurden eine Vision, Projektidee und Projektzielsetzung für das Integrationsprojekt definiert sowie vorbereitende Maßnahmen für eine
Go-Entscheidung der Geschäftsführung getroffen. Auch das Planen des Projektvorgehens und die Erstellung des Projektplanes war Teil dieser Phase. Ebenso wurde
festgehalten, dass evolutionäres Prototyping zur Anwendung kommen soll, um
möglichst frühzeitig eine lauffähige Version der vorläufigen Plattform zu erhalten.
Nach einer Analysephase sollen die Implementierungs- und Evaluierungs-Phasen,
zerlegt in mehrere Iterationen, ablaufen. Stakeholder sind von Beginn an - dh. von
der Analysephase bis zu Evaluierung der Zwischen- und Endergebnisse - in das
Projektgeschehen einzubinden. Detailplanungen und Releases der Plattform sind im
Rahmen des Projektmanagement zu erstellen und abzustimmen.
Unabhängig von den drei strategischen Geschäftsbereichen bei Teufelberger waren
vom Projekt Intranet T2.0 vor allem die F&E-Abteilungen und F&E-nahe Bereiche
betroffen. Aber auch andere Abteilungen des Unternehmens, wie der Einkauf oder
das Qualitätsmanagement wurden vom Projekt beeinflusst. Eine wichtige Rolle in
diesem Zusammenhang spielte auch das Produktmanagement, das die Kommunikationsschnittstelle zwischen F&E und den Abteilungen Marketing, Vertrieb und Produktion darstellt. Der Hauptfokus des Projektes lag daher auf wichtigen, geschäftsbereichsübergreifenden Prozessen und weniger gut funktionierenden bereichsinternen
Abläufen. Da die drei Geschäftsbereiche sehr eigenständig geführt werden, im Vollausbau alle Standorte vernetzt sein werden und der Vernetzungsgedanke in Zukunft
auch nach außen hin zu Lieferanten, Kunden, Systemherstellern und Forschungsei-
203
richtungen getragen werden soll, kann das Projekt als inner-, über- und zwischenbetriebliches Integrationsprojekt bezeichnet werden.
Die Rollenverteilung beim Projekt Intranet T2.0 zwischen den beiden Projektpartnern
FH Steyr und Teufelberger hat folgende Aufgaben- und Tätigkeitsaufschlüsselung
vorgesehen:

FH Steyr: Projektleitung, Projektdurchführung, Evaluierung, Schulungen,
Übergabe der Projektergebnisse, Dokumentation, Abnahme

Teufelberger: Projektmanagement, Informationsbereitstellung, Portierung der
Ergebnisse auf die Infrastruktur bei Teufelberger (gemeinsam mit FH), unternehmensweite Ausrollung, Anwenderschulungen über die Beta-Benutzer hinaus
Alle diese Informationen wurden in einem Kooperationsvertrag schriftlich festgehalten
und das Projekt wurde mit einem gemeinsamen Kick-Off gestartet.
8.2.2.2 Analyse
Die Analysephase umfasste eine Erfassung der Ist-Situation aus organisatorischer
(Struktur und Aufbau der Organisation, involvierte Stakeholder), prozessorientierter
(involvierte Geschäftsprozesse) und technischer Sicht (vorhandene technische
Infrastruktur und relevante Informationssysteme).
Im ersten Schritt wurden relevante Dokumente studiert (Aufbau der Organisation,
Dokumentation des Vorprojekts „ePresence“, mögliche zu involvierende Prozesse
und Beta-Benutzer).
Im Zuge der Analyse wurden neun Workshops mit je zwei bis drei Teilnehmern
durchgeführt. Eine Stakeholderanalyse der Teilnehmer zur Vorbereitung auf die
Workshops zeigte, dass der Großteil der involvierten Personen (>80%) dem Projekt
„positiv“ oder zumindest „neutral“ gegenüber steht. In diesen Workshops wurde
schließlich zu Beginn von den Teilnehmern je ein bestimmter, relevanter Prozess
(aus den im Vorfeld erhobenen, projektrelevanten Prozessen) durch Punktevergabe
identifiziert und der Prozess mit der höchsten Punkteanzahl ausgewählt.
Dieser Prozess wurde anschließend gemeinsam erarbeitet und modelliert. Danach
wurde in einem semi-strukturierten Interview die Kommunikation, Dokumentation,
Prozessunterstützung und Innovation im modellierten Prozess erhoben sowie
Schwachpunkte und Verbesserungspotentiale identifiziert. Die Detaillierung bzw.
Erhebung lief nach einem vorher definierten, strukturierten Leitfaden ab610.
610
Ein Leitfaden für das semi-strukturierte Interview bei den Workshops befindet sich im Anhang
(Anhang D: Interviewleitfaden für die Workshops in den Pilotprojekten).
204
Die zusätzliche Erfolgsfaktorenanalyse sollte helfen, die Ist-Situation in den relevanten Anwendungsszenarien zu erheben. In einem Fragebogen konnten die Befragten eine Bewertung der Ist-Leistung und der Priorität vornehmen. Insgesamt umfasste der erstellte Fragebogen 21 Fragen zur Beurteilung identifizierter Themengebiete
sowie der persönlichen Zielsetzung und individuellen Aufgabensituation611. Zusätzlich gab es die Möglichkeit, zu den Fragen offene Anmerkungen hinzuzufügen.
An der Umfrage nahmen 24 Personen teil. 18 Fragebögen wurden hierbei in den
Workshops persönlich an die Teilnehmer ausgegeben und zusätzlich wurden an die
weiteren Beta-Benutzer aus den Abteilungen F&E und Einkauf (25 Personen) per
Mail versendet. Die Rücklaufquote betrug demnach 56%.
Die Auswertung der Antworten ermöglichte es, die Erfolgsfaktoren in Abhängigkeit
der ermittelten Ist-Leistung und Priorität abzubilden. Die Mittelwerte dieser zwei
Dimensionen gliedern die grafische Darstellung der Faktoren in vier Felder oder
Quadranten, wodurch Hinweise auf den Handlungsbedarf hinsichtlich der Erfolgsfaktoren sichtbar gemacht werden können:
611

Quadrant I „Improve“: (Niedrige Leistung, Hohe Priorität): Die Faktoren dieser Gruppe sind hinsichtlich Verbesserungsmaßnahmen zu untersuchen, um
die Leistung an die Priorität anzupassen.

Quadrant II „Sub Relevant“: (Niedrige Leistung, Mittlere Priorität): Es besteht
kein akuter Handlungsbedarf in dieser Gruppe, da die Faktoren meist eine geringe Differenz zwischen Priorität und Leistung aufweisen.

Quadrant III „Well Done“: (Hohe Leistung, Hohe Priorität): Für Faktoren in
dieser Gruppe besteht kein Handlungsbedarf, da sowohl Leistung als auch
Priorität als gut eingeschätzt wurden.

Quadrant IV „Exceeding Performance“: (Hohe Leistung, Mittlere Priorität):
Anstrengungen und Investitionen in dieser Gruppe sind evtl. reduzierbar, da
die Priorität keine hohe Leistung benötigt. Allerdings wurde im Durchschnitt
bei allen Faktoren keine geringe, sondern zumindest eine mittlere Priorität
(Durchschnitt der Priorität = 1,8) gewählt.
Die abgefragten Erfolgsfaktoren des Fragebogens befinden sich im Anhang (Anhang E: Fragebogen zu Erfolgsfaktoren bei Teufelberger).
205
Abbildung 56: Auswertung der Erfolgsfaktoren nach Prioritäts-Leistungs-Quadranten (eigene Darstellung)
Die Auswertung der Erfolgsfaktoren nach Quadranten liefert das in Abbildung 56
dargestellte Ergebnis. Die Auswertung zeigt eindeutige Kritikpunkte (Quadrant I) an
den derzeitigen Instrumenten für einen schnellen Wissensaustausch und an Aspekten (Prozess, Strategie, Verankerung, Bekanntheit, Freiräume, Ziele etc.) zum Thema Innovation. Diese Punkte galt es bevorzugt zu adressieren.
Die gesammelten Analyseergebnisse wurden vor der Geschäftsführung präsentiert
und besprochen. Ein zusammenfassendes Analysedokument wurde erstellt.
8.2.2.3 Design
Die Ergebnisse aus den vorgestellten Analysemethoden bildeten den Ausgangspunkt
für die dritte Projektphase. Zunächst wurden die in den einzelnen Workshops erhobenen Anforderungen an einen typischen Soll-Prozess in Anwendungsszenarien
aggregiert und die notwendigen Funktionalitäten zugeordnet. Diese Anwendungs-
206
szenarien wurden anschließend priorisiert und die wichtigsten vier für die Umsetzung
des ersten Prototyps ausgewählt.
Zusätzlich zu den Funktionalitäten in den Anwendungsszenarien wurden auch Anforderungen allgemeiner bzw. bereichsübergreifender Natur und Rahmenbedingungen
definiert und beim Design berücksichtigt. Den zuvor in der Analysephase erhobenen
Anforderungen wurden also konkrete Funktionalitäten gegenübergestellt. Ein Beispiel, wie die spätere Lösung vom Aufbau her aussehen sollte, stellt nachfolgendes
Design eines Ideen-Blogs („IdeaBoard“) dar (Abbildung 57).
Abbildung 57: Design der „IdeaBoard“-Funktionalität (eigene Darstellung)
Die technische Ziellandschaft war durch die bereits existierende Infrastruktur vorgegeben. Das bestehende Intranet lief bereits auf Microsoft Sharepoint (Version 2003),
weshalb dies auch für das Intranet T2.0 gelten sollte. Im Design wurde aufgezeigt,
welche Funktionalität auf welcher Sharepoint Version (Foundation vs. Server) standardmäßig zur Verfügung steht. Dieser Punkt sollte insbesondere aufzeigen, ob und
falls ja, aus welchen Gründen ein Umstieg auf den lizenzpflichtigen Microsoft
SharePoint Server 2010 nötig ist.
8.2.2.4 Realisierung
Bei der Implementierung orientierte man sich an der „Perpetual Beta“ Entwicklung.
Hier sollte möglichst früh im Projekt ein Prototyp, also eine nutzungsfähige („Beta“)
Version der Lösung Intranet T2.0 vorhanden sein, um die Funktionsfähigkeit direkt
durch die Nutzer selbst evaluieren lassen zu können. Es sollten möglichst rasch
eventuell noch nicht oder nicht umfassend berücksichtigte Benutzeranforderungen in
die Weiterentwicklung mit einfließen können.
207
Die Entwicklung eines ersten Prototyps erfolgte zuerst auf einer Beta-Version des
Microsoft SharePoint Servers 2010 an der FH Steyr, um die grundlegenden Funktionen und Systemeigenschaften zu erheben. Der erste Prototyp für den Testbetrieb
wurde anschließend auf der Release-Version des Microsoft SharePoint Servers 2010
erstellt. Parallel dazu wurde bei Teufelberger die Serverlandschaft an die Anforderungen des Prototyps angepasst.
Nachdem bei Teufelberger diese Umrüstung bzw. das Upgrade auf den Microsoft
SharePoint Server 2010 abgeschlossen war, erfolgte das Rollout des an der FH
entwickelten ersten Prototyps bei Teufelberger und der erste Testbetrieb konnte
beginnen. Das Rollout wurde gemeinsam mit den späteren Administratoren der
Plattform durchgeführt und im Zuge dessen entsprechend geschult.
8.2.2.5 Betrieb und Weiterentwicklung
Die Weiterentwicklung des Prototyps lief in sich wiederholenden Zyklen von (Test-)
Betrieb und Weiterentwicklung ab, bis dieser als Echtsystem eingesetzt werden
konnte. Die Beta-Phase startete im Juni 2010 und wurde mit 50 Nutzern getestet. Die
Beta-Benutzer erhielten jeweils in Kleingruppen zu 8 bis 10 Personen eine 2stündige Einschulung in das System. Im Zuge der Schulung wurden auch Usability
Tests zur Evaluierung durchgeführt (heuristische Evaluierung und Eye-Tracking
Analyse).
Für die heuristische Evaluierung wurden Fragebögen angefertigt. Neben der
Evaluierung eines Gesamteindrucks waren die abgefragten Heuristiken die Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Steuerbarkeit, Erwartungskonformität, Fehlertoleranz, Individualisierbarkeit und Lernförderlichkeit. Im Ziel der
Bewertung lagen insgesamt acht Bereiche des Prototyps (Hauptmenüführung, MySite, T2.0 Home, CEO-Blog, IdeaBoard, Tagging, Bewertung und persönliches
Profil). Zuerst wurde der Gesamteindruck des abgefragten Bereichs nach dem
Schulnotensystem von 1 (hervorragend) bis 5 (ungenügend) abgefragt. Die weiteren
Heuristiken wurden danach auf einer 5-stufigen Skala bewertet: 0 (kein Usability
Problem), 1 (kosmetisches Problem), 2 (bedenkliches Problem), 3 (schwerwiegendes
Problem) und 4 (katastrophales Problem).
Ein Usability-Experte hat in einer geführten Interview-Situation die Evaluierung mit
sechs Probanden direkt nach der Schulung durchgeführt. Schulungsleiter war eine
andere Person als der Usability-Experte612, um ein möglichst ehrliches und unbefangenes Feedback zu erhalten. Ergebnis der Auswertung war, dass der Gesamtein-
612
Beide waren aus Sicht des Unternehmens Teufelberger externe Personen der FH Steyr.
208
druck im Schnitt zwischen 2 und 3 bewertet wurde. Abbildung 58 zeigt die Ergebnisse je Bereich im Detail, der Mittelwert über alle Bereiche lag bei 2,45.
Abbildung 58: Heuristische Evaluierung - Auswertung des Gesamteindrucks (eigene Darstellung)
Wichtiger als das quantitative Ergebnis waren aber die qualitativ erhobenen Eindrücke der Benutzer im Zuge des Interviews. Hauptkritikpunkte waren vor allem folgende:

Im ersten Prototyp wurden zwei Kanäle zum Feedback eingesetzt: ein Feedback-Wiki und ein Feedback-Blog. Diese Dualität bzw. Redundanz durch zwei
Feedback-Kanäle wurde bemängelt und sollte vermieden werden. Deshalb
etablierte sich im Projektverlauf der Feedback-Blog als Standard FeedbackKanal und das Feedback-Wiki wurde verworfen.

Bei der Bewertung der Heuristiken je Bereich lagen die größten Mängel in der
Selbstbeschreibungsfähigkeit. Kommentare bzw. die Begründung der schlechten Bewertung dieser Heuristik gingen meist in Richtung „Wie finde ich…“,
„Wo ist…“, oder etwas ist „zu versteckt“. Auch fehlende Links bzw. ZurückLinks, zu hohe Komplexität oder unklare Strukturen und Regelungen wurden
bemängelt.

Als „kleinere Probleme“ wurden Punkte wie eine fehlende Datumsanzeige
oder zu wenig Erklärung bzw. Hilfe zu einzelnen Funktionalitäten (z.B. im Bereich Tagging und Bookmarking) genannt.
Diese Ergebnisse lieferten trotz der geringen Anzahl an Probanden wichtiges Feedback für die Weiterentwicklung des Systems und für eine den Bedürfnissen der
Anwender entsprechende Gestaltung des Intranet T2.0.
Eine Eye-Tracking Analyse wurde als zusätzliche Evaluierung im Zuge der Einschulung in den Prototyp durchgeführt. Die Erhebung umfasste sechs Probanden vor der
209
Intranet T2.0 Schulung und weitere sechs Probanden wurden nach der Schulung
abgewickelt. In Summe weist die Eye-Tracking-Analyse also einen Umfang von 12
Teilnehmern auf. Dieses Vorgehen sollte zum einen erheben, wie intuitiv ungeschulte
Nutzer mit dem neuen System zurechtkommen. Zum anderen sollte aufgezeigt
werden, wie die Schulung den Umgang mit dem System beeinflusst.
Anhand der Ergebnisse konnte belegt werden, dass die Schulung in den meisten
Bereichen einen positiven Einfluss auf den Umgang mit dem System hatte. Die
Zeitdauer, die die Befragten bis zum ersten Blick auf den gesuchte Bereich benötigten („Time to first Fixation“ in Sekunden), war nach der Schulung meist deutlich
niedriger als vorher (siehe Abbildung 59)613.
Abbildung 59: Eye-Tracking Analyse: Benötigte Zeit zum Auffinden (“Time to first Fixation“) (eigene
Darstellung)
Anhand von Heatmaps und Scan-Pfaden können die Ergebnisse des Eye-Tracking
auch grafisch dargestellt werden. Als Beispiel werden die Scan-Pfade zweier Probanden zur Auffindung des „I-Like-It“ Tags vor nach der Schulung gegenübergestellt
(Abbildung 60). Der „I-Like-It“ Tag, den es im Beispiel zu fixieren galt, befindet sich
im rechten oberen Bereich der Webseite. Die Darstellung des Pfades, also der Kombination aus den fixierten Punkten614 und den Sakkaden615, zeigt, dass vor der Schulung eher unstrukturiert und wenig zielgerichtet nach dem gesuchten Bereich gesucht
wurde. Nach der Schulung wurde der Blick als erstes auf den gesuchten „I-Like-It“
613
Die Daten wurden mit einem 120Hz Eyetracking-System von Interactive Minds aufgezeichnet. Zur
Auswertung wurde die Software Nyan 2.3.5 verwendet.
614
Fixationen werden als rote Kreise dargestellt. Je länger ein Punkt fixiert wurde, desto größer der
Kreis.
615
Sakkaden kennzeichnen den Weg, den der Blick nahm, und werden als grüne Linie zwischen den
Kreisen dargestellt.
210
Tag gerichtet und verweilte auch dort, wie durch nachfolgende Abbildung sichtbar
wird.
Abbildung 60: Scan-Pfade zum „I-Like-It“ Tag vor der Schulung (links) und nach der Schulung
(rechts) (eigene Darstellung)
Die Notwendigkeit einer Schulungs- und Eingewöhnungsphase sowie eines Testbetriebs kann durch die Gegenüberstellung der vorher und nachher Ergebnisse dieser
Eye-Tracking Studie belegt werden. Vielmehr jedoch trägt die Eye-Tracking Studie
durch die weitere Involvierung der Nutzer auch zur Erhöhung der Motivation bei. Dies
ist eine weitere Möglichkeit zur Steigerung der Partizipation und wirkt positiv im Sinne
des Projektmarketing.
Als ergänzende Möglichkeit der Evaluierung stand den Nutzern ein Feedback-Blog
zur Verfügung. So konnten Anmerkungen und Inputs der Nutzer bei der stufenweisen
Weiterentwicklung der Lösung berücksichtigt werden. Bis Oktober 2010 wurden von
den Anwendern im Feedback-Blog 53 Beiträge für Verbesserungsvorschläge bzw.
Fehler eingebracht. Der Einsatz des Feedback-Blogs hat hierbei zur guten Nutzung
des Systems wesentlich beigetragen. So wurde während der Entwicklung des Intranets T2.0 schon ein zukünftiger Bestandteil dieser Lösung – nämlich der FeedbackBlog im Testsystem – als Rückmeldungs- und Kommunikationskanal verwendet. Dies
ermöglichte es den Anwendern einerseits, einen ungezwungenen, direkten Feedback-Kanal zum Entwicklerteam aufzubauen. Andererseits konnten sie durch das
eigene Feedback das Erstellen von Blogeinträgen trainieren und das Intranet T2.0
nutzen.
Der Beta-Betrieb wurde mit den letzten Updates bis Ende Dezember 2010 fortgesetzt. Im Laufe des Jahres 2011 wurden die Inhalte des bestehenden Intranets auf
die Sharepoint Server 2010 Infrastruktur portiert und danach mit den Inhalten aus
211
dem gegenständlichen Projekt Intranet T2.0 verschmolzen. Ein flächendeckendes
Rollout über alle Standorte war erst nach dieser Verschmelzung sinnvoll. In Zukunft
ist es geplant, den Vernetzungsgedanken über die T2.0 Plattform hinweg auch nach
außen hin zu Lieferanten, Kunden, Systemherstellern und Forschungseinrichtungen
zu tragen.
8.3 Pilotprojekt 2: Lieferanten- und Kundenintegration bei NKE
Das zweite Pilotprojekt behandelt die Konzeption und prototypische Umsetzung einer
Integrationslösung zum zwischenbetrieblichen Informationsaustausch bei der NKE
Austria GmbH.
Das Unternehmen. NKE Austria GmbH ist ein österreichisches Unternehmen mit
Hauptsitz in Steyr, Oberösterreich. Das 1996 als NKE Wälzlager Vertriebsges.m.b.H.
gegründete Unternehmen produziert Premium-Qualitäts-Wälzlager, die durch 15
Vertriebsbüros und ein Netzwerk von mehr als 240 Händlern in 60 Ländern weltweit
vertrieben werden. Mit mehr als 200 Mitarbeitern erwirtschaftete der Konzern im Jahr
2009 einen Umsatz von 43,8 Millionen Euro. Die Produkte von NKE lassen sich grob
in die drei Kategorien Standardlager (genormte Ausführungen von mehr als 6000
Wälzlager-Typen), Sonderlager (bspw. in Drehzahl oder Belastbarkeit von der Norm
abweichende Wälzlager) und Anwendungen (spezielle Lösungen für spezifische
Anwendungsfälle wie bspw. in den Bereichen Pumpen, Schienenfahrzeuge, oder
Windenergie) unterteilen. Zu den Dienstleistungen und Lösungen, die NKE anbietet,
zählen einzelne Wälzlager und Lagereinheiten, aber auch Unterstützung bei der
Konzeptentwicklung bis hin zur Serienfertigung.
Vision. Die Vision hinter dem gegenständlichen Projekt war die Konzeption und
Umsetzung einer webbasierten Plattform zum zwischenbetrieblichen Informationsaustausch, in der von berechtigten Lieferanten und Kunden relevante Informationen
aufgefunden, eingesehen, verlinkt, kommentiert, kategorisiert und visualisiert werden
können.
Stellenwert von IT und Integrationstechnologien. Die IT spielt bei NKE eine
wichtige Rolle. Ein Grund dafür ist die Tatsache, dass in vielen Bereichen bereits
spezielle Informationssysteme zur Prozessunterstützung eingesetzt werden. Neben
einem ERP-System und einem System zum Qualitätsmanagement existiert bspw.
auch ein eigenes Lagerverwaltungssystem. Technologien zur betrieblichen Integration spielen aufgrund der starken IT-Affinität nicht nur von der IT-Abteilung selbst,
sondern auch speziell von der Projektmanagement-Abteilung eine große Rolle. Die
212
Leiter dieser beiden Abteilungen vermitteln die Grundeinstellung zur Technologie
auch an den Rest des Unternehmens.
Integrationsbedarf. Ein wesentlicher Anstoß für das Projekt war ein zunehmend
verschärfter Wettbewerb, was auch auf die Wirtschaftskrise und ihre Auswirkungen
ab 2007 zurückzuführen ist. Als Reaktion auf diese Entwicklung wurde der Entschluss gefasst, dass der Zusammenarbeit mit Partnern entlang der Wertschöpfung
in Zukunft eine größere Rolle beigemessen werden soll. Dies resultierte darin, dass
man sich bei NKE verstärkt auf Themen wie erhöhte Kundenbindung, gefestigte
Lieferantenbeziehungen, gesteigerte Beziehungsqualität zu Partnern in der Lieferkette und auf gegenseitiges Vertrauen konzentrieren wollte. All diese Maßnahmen
haben eine verbesserte Kooperation, vereinfachte Kommunikation und einen optimierten Datenaustausch gemeinsam. So entstand die Idee zur Lieferanten- und
Kundenintegration eine inner-, über- und zwischenbetriebliche Plattform zum Informationsaustausch einzuführen.
In der Folge werden wesentliche Tätigkeiten und Methoden aus den Projektphasen
Orientierung, Analyse, Design, Realisierung, und Betrieb beschrieben.
In der ersten Phase wurden die Projektvision und -idee sowie die Zielsetzung definiert. Ein Projektplan mit wesentlichen Phasen und Meilensteinen wurde erstellt und
die Unterstützung von der Geschäftsführung wurde eingeholt.
Vom Projekt waren neben dem Einkauf und dem Vertrieb vor allem die Projektmanagement- und die IT-Abteilung des Unternehmens betroffen. Aus strategischer Sicht
war die Projektmanagement-Abteilung am stärksten betroffen. In dieser Abteilung
wurde die Realisierung des Projekts geplant, organisiert und koordiniert. Darüber
hinaus befanden sich in dieser Abteilung auch die verantwortlichen Personen für den
späteren laufenden Echtbetrieb.
Den administrativen Part im Projekt und im laufenden Betrieb übernahm zum Großteil die IT-Abteilung. Diese war im Zuge des Projektes für die Umsetzung der strategischen Vorgaben aus der Projektmanagement-Abteilung und in späterer Folge für
den laufenden Betrieb und die Weiterentwicklung der Plattform zuständig.
Auf operativer Ebene waren wiederum die Fachabteilungen (Einkauf und Vertrieb)
betroffen, die direkt mit der Integrationslösung arbeiten und durch das Projekt den
größten Nutzen durch Prozessveränderungen haben sollten. Vor allem im Bereich
der Kommunikation und des Informationsaustausches mit Lieferanten und Kunden
213
wurden hier wesentliche Neuerungen erwartet, die von den internen Nutzern akzeptiert und in die täglichen Arbeitsabläufe der einzelnen Mitarbeiter integriert werden
müssen.
Die Besonderheit in diesem Projekt war, dass von Beginn an folgende Teilprojekte im
Projekt vorgesehen waren:

“Readiness“ für Informationsaustausch: Interne Vorbereitungsmaßnahmen
für die zwischenbetriebliche Bereitstellung von Informationen im Rahmen der
gemeinsamen Ist-Analyse mit NKE und potentiellen Partnern auf Kunden- und
Lieferantenseite und Durchführung der notwendigen Maßnahmen zur Informationsbereitstellung im ERP-System von NKE.

Lieferanten-Informationssystem: Bereitstellung von Informationen in einer
prototypischen Plattform zur Effektivitäts- und Effizienzsteigerung in der Bestellabwicklung von der Anfrage bis zur Anlieferung zwischen NKE und seinen
Lieferanten. Dies soll durch eine zeitnahe Zurverfügungstellung von Informationen inklusive Integration von ERP Daten und Dokumenten und Erhöhung der
Transparenz erreicht werden.

Kunden-Informationssystem: Bereitstellung von relevanten betrieblichen Informationen aus dem ERP-System in einer prototypischen Integrationslösung
für berechtigte Kunden.
Die Rollenverteilung zwischen FH Steyr und NKE hat folgende Aufgaben- und Tätigkeitsaufschlüsselung vorgesehen:

FH Steyr: Projektleitung, Projektdurchführung, Evaluierung, Schulungen,
Übergabe der Projektergebnisse, Dokumentation, Abnahme.

NKE: Projektmanagement, Informationsbereitstellung, Aufbau der Infrastruktur, Portierung der Ergebnisse auf die Infrastruktur bei NKE (gemeinsam mit
FH), Betrieb der Integrationslösung, unternehmensweite Ausrollung, Anwenderschulungen über das Kernteam hinaus.
Um eine einheitliche Ausgangsbasis und ein gemeinsames Projektverständnis herzustellen, wurde ein offizielles Kick-Off Meeting, in dem auch die einzelnen Bereichsleiter über die Ziele und Inhalte der geplanten Integrationslösung informiert wurden,
durchgeführt.
8.3.2.2 Analyse
Die Analysephase umfasste wiederum organisatorische, prozessorientierte und
technische Gesichtspunkte. Eine Stakeholderanalyse wurde nicht auf Einzelpersonen, sondern auf Gruppenebene durchgeführt. Die Einstellung einer Abteilung zum
214
Projekt ist dabei oft durch den jeweiligen Abteilungsleiter geprägt. Die Analyse ergab
folgendes Bild:

Geschäftsführung: Der Projektauftraggeber ist die Geschäftsführung von
NKE. Diese wird als offen für zukunftsträchtige Projekte und veränderungsfreundlich eingestuft.

Projektmanagement: Ebenso verhält es sich mit dem späteren Anwendungseigner und Träger der internen Projektleitung, der Projektabteilung: auch
hier sind zukunftsorientierte Projekte gern gesehen.

IT-Abteilung: Die IT-Abteilung, die auch sehr stark in das Projekt eingebunden ist, ist grundsätzlich positiv gegenüber Neuem eingestellt, verfolgt jedoch
eine eher sicherheitsorientierte IT-Strategie. Hier muss damit gerechnet werden, dass bei vielen Punkten kritisch hinterfragt wird.

Fachabteilungen: Die betroffenen Fachabteilungen (v.a. Einkauf, Vertrieb)
sind aufgrund ausgelasteter Kapazitäten sehr nutzenorientiert: Hier werden
vor allem jenen Projekten Ressourcen zugeteilt werden, die aus Sicht der jeweiligen Abteilung auch einen raschen Nutzen für das tägliche Geschäft mit
sich bringen.

Lieferanten: Die Lieferanten profitieren von dem Projekt. Die derzeitige
Kommunikation läuft asynchron per E-Mail oder Telefon und führt besonders
bei unterschiedlichen Zeitzonen zu stark erhöhten Durchlaufzeiten: Hier wird
damit gerechnet, dass vor allem weit entfernte Lieferanten aufgrund der Zeitverschiebung das Projekt positiv aufnehmen.

Kunden: Wie die Lieferanten, profitieren auch die Kunden von mehr Transparenz und Echtzeitinformationen durch das Projekt. Auch hier wird erwartet,
dass das Projekt positiv gesehen wird.
Die technische Analyse zeigte, dass sich die projektrelevante Infrastruktur aus dem
bestehenden ERP-System des Unternehmens und dem Lagerverwaltungssystem
zusammensetzt. Um die geplanten Projektziele erreichen zu können, war eine Integration mit diesem ERP-System und der zu realisierenden Integrationslösung von
grundlegender Bedeutung. Auch das vorhandene Lagerverwaltungssystem war –
wenn auch nur indirekt – zur projektrelevanten Infrastruktur zu zählen. Die Gesamtbestände mussten in die Integrationslösung übernommen werden können, um in
weiterer Folge den Kunden eine eigenständige Überprüfung von Verfügbarkeiten
ermöglichen zu können. Diese Integration zwischen der entwickelten Plattform und
dem Lagerverwaltungssystem sollte indirekt über das ERP-System erfolgen.
Beim Schwerpunkt Lieferantenintegration wurden einerseits internen Anforderungen
aus fachlicher und prozessorientierter Sicht der beschaffungsnahen Abteilungen, der
215
Logistik-, SCM- und Produktionsabteilung, die der Qualitätsmanagement-Abteilung,
der Konstruktion und jene der Geschäftsführung mittels Befragung mit betroffenen
Personen erhoben. Die prototypische Implementierung sollte am Beispiel eines
wichtigen Lieferanten, der Firma DHK in China, durchgeführt werden. Die Anforderungen seitens Lieferanten wurden über ein telefonisches Interview erhoben. Als
typisches Beispiel für einen E-Mail und Telefon gestützten Ist-Prozess wird der
Bestellanfrageprozess dargestellt. Wie durch Abbildung 61 deutlich wird, weist dieser
Ist-Prozess zahlreiche Kommunikationsschleifen auf. Diese Art der asynchronen
Kommunikation führt besonders im konkreten Beispiel bei unterschiedlichen Zeitzonen (China und Österreich) zu stark erhöhten Durchlaufzeiten und erzeugt Fehler
durch Medienbrüche in der Erfassung.
Abbildung 61: Bestellanfrage Ist-Prozess zwischen NKE und Lieferant DHK (eigene Darstellung)
216
Die zweite Analysephase zum Schwerpunkt Kundenintegration lief analog ab. Als
Pilotkunde wurde die Firma Global Bear Inc. aus Kanada ausgewählt, die als Informationsquelle für die externen Anforderungen herangezogen wurde.
8.3.2.3 Design
Für die Herstellung der „Readiness“ im ersten Teilprojekt lag der Fokus in dieser
Projektphase auf dem Wissensaufbau für die geplante Infrastruktur, der Definition der
Serverstruktur und dem Bereitstellen der für den späteren Betrieb der Plattform
benötigten IT-Infrastruktur. Da die Einbindung des ERP-Systems an die Integrationslösung tiefergreifendes Know-How und Programmierung bedingte, wurde ein externer Partner für die Realisierung ausgewählt.
Für die Realisierung der Integrationslösung wurde auf Microsoft Sharepoint 2010
gesetzt. Der vorrangige Grund war die bereits existierende, auf Microsoft basierende
Serverinfrastruktur. Zusätzlich hat sich NKE von dieser Sharepoint Version vor allem
in Kombination mit der aktuellen Office Umgebung (Microsoft Office 2010) verbesserte Möglichkeiten der Integration versprochen. Zu beachten war, dass die vorhandene
Serverinfrastruktur für eine flüssige Laufzeit und akzeptable Performance nicht
ausreichend gewesen ist und aufzurüsten war.
Weiters war der Einsatz von Middleware (Microsoft Biztalk) zur Anbindung der Kunden und Lieferanten angedacht. Aufgrund der hohen Anschaffungskosten wurde dies
im Zuge des Projektes wieder verworfen, da im ersten Schritt nur ein Pilotbetrieb mit
einzelnen Lieferanten und Kunden geplant war.
Die internen und externen Anforderungen für die Lieferanten- und Kundenintegration
wurden wiederum bewertet und priorisiert, die wichtigsten zur Realisierung ausgewählt und ein Umsetzungsplan erstellt.
Als Vorgehen bei der Entwicklung der Plattform wurde auf evolutionäres Prototyping
gesetzt. Die Evaluierungen und schrittweisen Verbesserungen des Prototyps finden
aus Projektsicht der FH Steyr zum Teil nach Projektabschluss statt und werden dann
selbstständig durch NKE vorgenommen. Wichtig war daher auch der Know-How
Transfer zwischen den involvierten Projektpartnern.
Die entwickelte prototypische Plattform besteht neben der Startseite aus einem
Downloadbereich, einem Einkaufsbereich und einem Kundenbereich.
Der Downloadbereich enthält, neben allgemein gültigen Dokumenten, relevante
Dokumente und Vorlagen, die für berechtigte Lieferanten abgelegt und eingesehen
werden können. Um die Suche und Verwaltung der Dokumente zu vereinfachen, sind
217
Schlagworte, Versionen und weitere Metainformationen zu den Dokumenten speicherbar.
Der Bereich „Einkauf“ ist für den NKE Einkauf und die Lieferanten zugänglich. Er
bietet Zugang zu offenen Anfragen sowie offenen und bestätigten Bestellungen. Die
Informationen werden dabei über das ERP-System in Echtzeit eingebunden.
Der Kundenbereich ist für den NKE Vertrieb und die Kunden zugänglich und bietet
Informationen über Aufträge im Rückstand und die Lagerliste mit Kundenpreisen, die
ebenfalls aus dem ERP-System stammen. Somit kann sowohl der Kunde selbst, als
auch der Vertrieb den aktuellen Stand an noch nicht erledigten Aufträgen und auf
Lager liegenden Produkte mit kundenspezifischen Preisinformationen einsehen.
Dadurch werden langwierige Rückkopplungs- und Kommunikationsschleifen, wie in
der Vergangenheit üblich, vermieden und der Bestellprozess aus Kundensicht deutlich verkürzt und vereinfacht.
Mit Betrieb des ersten Prototyps startete auch der Know-How Transfer. Ziel war es,
das Entwicklungs-Know-How durch Schulung der künftigen Administratoren und des
NKE Entwicklerteams weiterzugeben. Dies konnte in Schulungen und direkten Gesprächen während der Entwicklung erreicht werden. Zusätzlich wurden die Endbenutzer entsprechend geschult.
Die besondere Herausforderung in diesem Projekt bestand in der Umsetzung des
evolutionären Prozesses, der schrittweise, im Unternehmen NKE beginnend, die
Partner in der Wertschöpfung integriert, um möglichst breite Akzeptanz unter den
Netzwerkpartnern zu erzielen. Zusätzlich war die Motivation und Einbindung wichtiger Akteure eine ständige Herausforderung, der im Sinne professionellen Projektmanagements durch die beiderseitige Projektleitung begegnet wurde. Die konsequente
Überwachung von Meilensteinen und dem Fortschritt im Allgemeinen war ein wesentliches Kriterium für den Erfolg des Projektes.
Das Projekt wurde aus Sicht der FH Steyr nach 16 Monaten Projektlaufzeit Ende
April 2011 mit einem offiziellen Abnahmedokument abgeschlossen. NKE kann die
realisierte Integrationslösung ab diesem Zeitpunkt eigenständig weiterbetreiben.
Durch die klare kommunizierte Vorgehensweise mit konsequenter Verfolgung der
Projektziele und Involvierung der Stakeholder, kann das Projekt in Summe als erfolgreich eingestuft werden. Die Zusammenarbeit mit externen Implementierungspartnern war jedoch enttäuschend und hat den Projekterfolg maßgeblich negativ beeinflusst. NKE muss den entwickelten Prototyp Schritt für Schritt weiter verbessern und
218
dafür sorgen, dass das neue System auch aktiv genutzt wird – sowohl intern als auch
extern.
8.4 Pilotprojekt 3: Standortübergreifende Innovationsnetzwerke
bei Fronius
Das dritte Pilotprojekt behandelt die Konzeption und prototypische Umsetzung von
Konzepten und Technologien zur betrieblichen Integration innerhalb des Unternehmens Fronius zur Unterstützung der Kommunikation und des Informationsaustausches. Spezieller Fokus wird auf die Umsetzung von standortübergreifenden, kooperativen Innovationsnetzwerken gelegt.
Das Unternehmen. Die Fronius International GmbH wurde 1945 durch Günter
Fronius in Pettenbach (Österreich) gegründet und ist ein österreichischer Produzent
von Batterieladesystemen, Schweißtechnik und Solarelektronik. Mit über 3200 Mitarbeitern an Standorten in 8 Städten in Österreich und in 18 Ländern weltweit wurde
2010 ein Jahresumsatz von 499 Mio. Euro erwirtschaftet. Fronius exportiert rund
95% seiner produzierten Waren und ist damit in über 60 Ländern geschäftstätig. Die
Sparte Batterieladesysteme existiert seit der Unternehmensgründung im Jahr 1945
und stellt damit die älteste Sparte bei Fronius dar. In den 1950er Jahren kam mit
Produkten aus der Schweißtechnik die zweite Sparte hinzu, die bis heute ein Standbein der Firma darstellt. Die jüngste Sparte ist die der Solarelektronik, die etwa seit
Mitte der 1990er Jahre mit der Gründung des Geschäftsfeldes Energie & Umwelt
besteht. Mit Ende des Geschäftsjahres 2011 arbeiteten fast 400 Mitarbeiter in der
Forschung und Entwicklung.
Vision. Die Projektvision sieht eine betriebliche Integration mit Konzepten und Technologien auf sozialer Ebene und Prozessebene vor. Zusätzlich sollen bestehende
betriebliche Informationssysteme und Daten bestmöglich eingebunden werden.
Durch die Verwendung von Enterprise 2.0 Konzepten soll eine Unterstützung des
Wissensmanagements und Förderung von Innovationen gewährleistet werden. Das
gegenständliche Projekt liefert daher vor allem zum Wissens- und Innovationsmanagement und somit auch zur Vision des Unternehmens als Ganzes einen wesentlichen Beitrag.
Integrationsbedarf. Der Grundstein wurde im Jahr 2009 durch die Arbeiten im Zuge
einer Diplomarbeit zur Verbesserung des Erfahrungstransfers in Entwicklungsprojek-
219
ten bei Fronius gesetzt616. Die Diplomarbeit war im Wissensmanagement angesiedelt
und beschrieb die Möglichkeiten eines Werkzeuges zur Strukturierung von Kompetenzen der Mitarbeiter in den verschiedenen Fachbereichen der F&E. Der Integrationsbedarf entstand aufgrund des hohen Firmenwachstums, welches sich auch in
den Personalzahlen in der Forschung und Entwicklung wiederspiegelte. Probleme in
der Transparenz und Bewahrung von Wissen wurden primär in den fachbereichsübergreifenden Forschungsgruppen geortet, die teilweise über mehrere Standorte
verteilt agieren. Vor allem bei einem Ausscheiden von Mitarbeitern bzw. die Aufnahme neuer Mitarbeiter entstehen Lücken, die geschlossen werden sollen.
Bei der Projektabwicklung wurde in Übereinstimmung mit dem Vorgehensmodell
speziell auf eine durchgehende Partizipation der Beteiligten geachtet, indem geeignete Methoden in den Phasen Orientierung, Analyse, Design, Realisierung, Evaluierung und Betrieb Einsatz fanden. Die nachfolgenden Kapitel beinhalten eine Beschreibung der in den Phasen durchgeführten Tätigkeiten.
Die erste Phase umfasste die Definition der Projektvision, Projektidee und die Zielsetzung. Der Integrationsbedarf wurde wie vorhin dargestellt mit einer Vorstudie
belegt. Ein Projektplan mit dem methodischen Vorgehen in Phasen und hinsichtlich
der zeitlichen Vorgaben (Meilensteine) wurde erstellt und abgestimmt. Die Rollen
zwischen der FH Steyr und Fronius wurden wie folgt definiert und in einem Kooperationsvertrag festgehalten.
Rollen der FH Steyr:
616

Projektleitung: Projektmanagement, Reporting und Qualitätskontrolle.

Methodische Begleitung bei der Projektdurchführung nach wissenschaftlich
anerkannter Methodik: partizipative Analyse, Design und Unterstützung bei
der Implementierung.

Evaluierung des Prototyps mit klassischen und aktuellen Usability-Methoden.

Schulung: Anwenderschulung der noch zu nominierenden Pilotanwendergruppe (vornehmlich Mitarbeiter der F&E-Abteilung, 10-15 Personen) zur Bedienung des Prototyps und Verfassen einer Benutzerdokumentation.
Vgl. Benz (2009)
220
Rollen von Fronius:

Projektmanagement: Projektleitung seitens Auftraggeber, Qualitätssicherung,
Informations-Schnittstelle zwischen Auftraggeber und Auftragnehmer

Informationsbereitstellung: Zur Verfügung stellen von ausreichend Personalressourcen zur Einholung der benötigten Informationen für das Projekt.

Aufbau der Infrastruktur und Betrieb des Prototyps: Die Projektergebnisse
laufen im Rahmen der Pilotanwendergruppe auf der Infrastruktur des Auftraggebers.

Unternehmensweite Ausrollung, Anwenderschulung über die Pilotanwendergruppe hinaus, Weiterentwicklung (über Customizing hinausgehende Programmierungen) und Support des Prototyps.
Die Geschäftsführung von Fronius beauftragte die Projektgruppe mit dem Projekt,
welches mit einem gemeinsamen Kick-Off offiziell gestartet wurde.
8.4.2.2 Analyse
Die Analysephase umfasste eine Erfassung der Ist-Situation von allen Integrationsdimensionen. Im ersten Schritt wurden relevante Dokumente studiert (Aufbau der
Organisation, Dokumentation der Vorarbeiten, mögliche zu involvierende Prozesse).
Aus technischer Sicht sind neben betrieblichen Informationssystemen wie das ERPSystem BaaN für das gegenständliche Projekt vor allem Systeme zur Unterstützung
des Informations- und Wissensmanagement von Interesse. Es soll ein Abgleich mit
folgenden bestehenden bzw. in Einführung befindlichen Softwareprodukten durchgeführt werden:

„Energy/net“: Klassische Intranet-Plattform mit aufbereiteten News, Vorstellung der Abteilungen und Personal, etc.

HRM-Software: Inhalt dieses laufenden Projektes ist die Einführung eines digitalen Personalakts mit Dokumentenverwaltung und Mitarbeiterdatenerfassung
als zentrale Informationsstelle für Führungskräfte, Mitarbeiter und Personalentwicklung.

Moodle: wird als Lernplattform von der Personalentwicklung (HR-Abteilung)
eingesetzt.

F&E-Abteilungen benutzen teilweise unterschiedliche Software-Lösungen zur
Dokumentation oder Bug-Tracking wie Fogbugz.

Terminologie-Datenbank: Eine Terminologie-Datenbank ist bereits weit fortgeschritten und kann nicht einfach ersetzt werden.
221
Nachfolgende Prozesse wurden als wissensintensive Prozesse angesehen und
daher als relevant für das Projekt erachtet:

Klassische themenspezifische Wissensdokumentation.

Themenbezogenes Netzwerk: Verbindung von Wissensträgern und Inhalten in
einem themenbezogenen Netzwerk.

Suchen und Finden von Wissensträgern: „Wer weiss was“ bzw. „Wer kann
was“.

Ideenmanagement: Generierung, Diskussion, Bewertung und Auswahl von
kreativen neuen Ideen (Innovationen).

Kommunikation: Sparten-, Abteilungs-, Projekt-bezogen und –übergreifend.

Alternative Kommunikationskanäle: Pull statt Push Kommunikation (Inhalte
abonnieren, E-Mail Flut entgegenwirken) und Austausch von Informationen.

Technologiemonitoring: Identifikation und Bewertung von Technologien.

FAQs: Dokumentationen zu Problemlösungen (z.B. für Kunden, andere F&E
Abteilung, Vertrieb, etc.).

Schnelle Entscheidungsfindung zu einem gewissen Thema.
Die bewusst klein gehaltene Gruppe an Beta-Anwendern wurde identifiziert (9 Personen aus F&E, 2 Personen aus Personalentwicklung, 2 Personen aus IT und je 1
Person aus dem technischen Support und aus der Prozesstechnik) und zu Workshops eingeladen. Es wurden sechs Workshops mit je zwei bis drei Personen
durchgeführt. In den Workshops wurde eingangs von den Teilnehmern durch Punktevergabe je ein relevanter Prozess identifiziert. Jede interviewte Person hatte maximal 3 Punkte zu vergeben, wobei diese auf 3 Prozesse verteilt, oder alle auf einen
Prozess gesetzt werden konnten. Ausgewählt wurde jener Prozess mit den meisten
Punkten. Nach der Auswahl wurden die Prozesse gemeinsam modelliert und in
Interviews detailliert besprochen. Tabelle 14 enthält eine Übersicht über die Punktevergabe (z.B. „Klassische themenspezifische Wissensdokumentation“ wurde in
Workshop Nr. 2 behandelt) und zeigt damit die Prioritäten der Workshopteilnehmer.
Tabelle 14: Punktevergabe in den Workshops (WS) bei Fronius
WS1
Themenspezifische Wissensdokumentation
Themenbezogenes Netzwerk
Suchen und Finden von
Wissensträgern
Ideenmanagement
Kommunikation
1
WS2
3
WS3
WS4
3
3
2
4
1
1
4
1
WS5
1
WS6
Gesamt
1
11
3
5
1
10
0
3
222
WS1
Informationsaustausch
Push vs. Pull
Technologiemonitoring
FAQs
Schnelle Entscheidungsfindung
WS2
2
WS3
1
WS4
1
WS6
Gesamt
1
4
4
4
4
1
1
WS5
3
1
1
4
Der Prozess mit der höchsten Punkteanzahl pro Workshop wurde gemeinsam mittels
Prozess-Kärtchen auf einer Pinnwand in durchschnittlich 6 Prozessschritten modelliert. Danach wurde in einem semi-strukturierten Interview die Kommunikation, Dokumentation und die Prozessunterstützung (erhoben und sowohl Schwachpunkte im
Prozess als auch Verbesserungsvorschläge identifiziert.
Darüber hinaus wurde in der Analysephase per E-Mail ein Online-Fragebogen zur
Durchführung einer Erfolgsfaktorenanalyse ausgesendet. Insgesamt wurden 38
Fragebögen ausgesendet. Der in der Auswertung berücksichtigter Rücklauf (N)
betrug 33 Fragebögen. Dies entspricht einer Rücklaufquote von 87%. Der Fragebogen wurde im Sep. 2011 über die Website Qualtrics.com online abgewickelt. Die
Auswertung lief analog wie im bereits beschriebenen Pilotprojekt 1 ab.
Zusammenfassend ließ sich feststellen, dass die Prioritäten der Themen aus den
Workshops mit den Befragungsergebnissen der Erfolgsfaktorenanalyse korrespondierten. Die themenspezifische Wissensdokumentation und das Suchen und Finden
von Wissensträgern waren ebenfalls die Topthemen aus Sicht der Workshopteilnehmer. Die wesentlichen Ergebnisse aus der Analysephase wurden als Projektdokumentation zusammengefasst.
8.4.2.3 Design
Das Design der Integrationslösung greift die in der Analyse erhobenen Schwachpunkte und den daraus resultierenden Anforderungen an idealtypische Soll-Prozesse
auf und versucht diese in Werkzeugen abzudecken.
Nach der Auswahl der wichtigsten Themen zur Umsetzung, den themenbezogenen
Netzwerken, dem Suchen und Finden von Wissensträgern („My-Site“), einigen Expertenfunktionen (damit ist die Erstellung von Workflows gemeint) und dem Ideensteckbrief als zusätzliches Quick-Win, wurden zusätzlich drei Feedbackrunden mit
je drei bis fünf Personen aus dem Kreis der Beta-Benutzer durchgeführt. Je Runde
wurde ein Thema ausgegeben und detaillierte Umsetzungsanforderungen gesammelt und diskutiert. Die Ergebnisse wurden in einem Feinkonzept dokumentiert.
Die Prämisse war, dass eine spätere Umsetzung mittels Microsoft Sharepoint Server
2010 möglich ist. Deshalb wurden in der Designphase den in der Analysephase
223
erhobenen Anforderungen konkrete Funktionalitäten von Sharepoint zugeordnet. Die
Nachvollziehbarkeit wurde durch Referenzen auf den/die Workshop(s) und die korrespondierenden Erfolgsfaktoren aus dem Fragebogen gewährleistet (siehe Abbildung 62).
Abbildung 62: Vorgehen beim Design der Lösung (Ausschnitt) (eigene Darstellung)
Die einzelnen Themen wurden in ein Gesamtkonzept gegossen, den Innovationsnetzwerken. Diese beinhalten Möglichkeiten zur Wartung der eigenen Personenprofile (inkl. Kompetenzen, Interessen, etc.) und der sozialen Kontakte innerhalb des
Unternehmensnetzwerkes. Die Personen können sogenannte „themenbezogene
Netzwerke“ gründen, beitreten und sich darin austauschen. Themenverantwortliche,
Technologiescouts und interessierte Personen können über themenbezogene Netzwerke (oder auch ad-hoc) Ideen erstellen, bewerten und diskutieren. Ideen haben
Ideenprofile, die wiederum zu Ideengruppen zusammengefasst werden können. In
monatlichen Sitzungen werden neue, innovative und kreative Vorschläge gemeinsam
besprochen. Das Ergebnis ist, dass eine Idee zurückgestellt, verworfen oder umgesetzt werden kann. Im Falle einer Umsetzung wird je nach Umfang ein Ideen- oder
Projektsteckbrief angelegt und aus dem System heraus ein mehrstufiger Umsetzungsworkflow gestartet.
Das in der Abbildung 63 dargestellte konzeptuelle Design wurde mit Funktionalitäten
für die zu entwickelnde Lösung hinterlegt. Hier wurde beispielsweise festgelegt, dass
themenbezogene Netzwerke aus einer Kombination von „Team Site“, „Blog“ und
„Tagging“ mit Microsoft Sharepoint umgesetzt werden sollen.
224
Abbildung 63: Konzeptionelles Design der Innovationsnetzwerke (eigene Darstellung)
Als Vorgehen bei der Entwicklung der Integrationslösung wurde auf evolutionäres
Prototyping gesetzt. Das konzeptuelle Design wurde von der FH Steyr direkt auf der
Infrastruktur von Fronius umgesetzt. Zunächst gab es einige Abstimmungen und
Tests zwischen der Projektleitung Fronius und FH und das Corporate Design wurde
umgesetzt, bevor die Beta-Benutzer mit einem ersten Test betraut wurden. Die Beta
Tests wurden auf eigenen Testservern bei Fronius durchgeführt, die Produktivserver
wurden erst in einer späteren Phase der Realisierung genutzt.
Das Innovationsnetzwerk wurde mittels Microsoft Sharepoint Server 2010 umgesetzt.
Die Realisierungs- und Betriebsphase liefen ab der ersten Beta Phase parallel ab. In
mehreren Release-Zyklen wurden Ergänzungen und Korrekturen am Prototyp vorgenommen.
Die im vorherigen Kapitel beschriebene Prototyping-orientierte Vorgehensweise
ermöglicht den frühen Betrieb eines lauffähigen Systems. Zu Beginn der ersten Beta
Phase wurde eine gemeinsame Schulung durchgeführt. Den Anwendern wurde das
System und dessen Funktionalitäten vorgeführt, auf Fragen wurde eingegangen und
Instruktionen für die erste Beta Phase wurden ausgegeben. Die Nutzer hatten die
Aufgabe, die Funktionalität zunächst einen Monat lang zu testen und Verbesserungsvorschläge in den dafür vorgesehenen Feedback-Blog zu posten. Danach gab
es eine persönliche Feedbackrunde, in der die aufgetretenen Hindernisse und ungelösten Einträge im Feedback-Blog besprochen wurden. Genannt wurden hier vor
225
allem Probleme mit der Navigation im System und damit verbunden das Auffinden
von manchen Funktionalitäten.
Danach wurden in mehreren Release-Zyklen Ergänzungen und Korrekturen vorgenommen (Zeitraum: November 2011 bis Mai 2012), die bei der Nutzung des Systems
aufgetreten sind. Die Evaluierungen und schrittweisen Verbesserungen des Prototyps finden aus Projektsicht der FH Steyr auch noch nach Projektabschluss statt und
werden durch Fronius vorgenommen. Wichtig war daher ein Know-How Transfer
zwischen den involvierten Projektpartnern.
Zum Know-How Transfer wurden zwei separate Schulungen durchgeführt. Die erste
Halbtages-Schulung wurde zur Hebung des Konzepts der Innovationsnetzwerke vom
Testsystem auf das Produktivsystem anberaumt. Die Anlage der Inhalte am
Sharepoint wurde daher manuell durchgeführt und die Anpassungen an den Seiten
wurden gemeinsam abgearbeitet. Anwesend waren die beiden Projektleiter sowie
eine Person der IT-Abteilung von Fronius. So konnten sowohl die Anwendersicht als
auch die des Systemadministrators geschult werden. Der zweite Know-How Transfer
hatte das Thema der Workflows zum Inhalt. Im speziellen wurde der Workflow des
Ideensteckbriefes am Produktivsystem gemeinsam angelegt und getestet.
8.5 Zusammenfassung
Zur Erprobung des Vorgehensmodells in der Praxis wurden drei Pilotprojekte mit den
Firmen Teufelberger, NKE und Fronius durchgeführt. Das Vorgehensmodell wurde
darin bei der Einführung betrieblicher Integrationslösungen im inner-, über- und
zwischenbetrieblichen Kontext angewendet. Der Blick auf den Bezugsrahmen in
Abbildung 64 zeigt wiederum die von den Projekten betroffenen Dimensionen und
Ebenen im Vergleich:

In allen drei Pilotprojekten wurde eine Strategie zur betrieblichen Integration
verfolgt und in der Orientierungsphase explizit dokumentiert und kommuniziert.

Auch alle drei Integrationsdimensionen waren in allen drei Projekten betroffen. So spielte beispielsweise der technologische Faktor „Kompatibilität“
die entscheidende Rolle in der Werkzeugauswahl. Aus der Dimension „Organisation“ ist die Top Management Unterstützung zu nennen, die in allen drei
Projekten gegeben war und auch zum Erfolg beigetragen hat. Im Pilotprojekt 2
war zusätzlich das Vertrauen in die Partnerschaft ein entscheidender Faktor
bei der Auswahl des Pilot-Kunden und -Lieferanten. Aus dem betrieblichen
Umfeld ist das Vorhandensein von externen Ressourcen für die Durchführung
der betrieblichen Integration zu nennen. In allen Projekten wurden externe
226
Partner in das Projekt eingebunden. Aber auch die Wettbewerbsintensität,
welche das Streben nach Effizienzsteigerung vorantreibt, spielte eine - wenn
auch untergeordnete - Rolle. Alle drei Dimensionen waren Gegenstand weiterer Untersuchungen im Zuge der Ist-Analyse.

Alle Integrationsebenen fanden in Summe bei den Pilotprojekten Anwendung. In allen drei Projekten war die Ebene der Prozesse und Services betroffen. Die Anwendungsszenarien waren auf eine Verbesserung und Einbindung
in den Arbeitsprozess ausgerichtet. Zwei der Projekte befassten sich intensiv
mit Konzepten und Technologien zur Integration auf der sozialen Ebene. Damit wurde die Lücke aus der Analysephase, in denen keine Beispiele mit Integrationslösungen auf sozialer Ebene gefunden wurden, geschlossen. Die
Ebene der Middleware war nur in Pilotprojekt 2 bei NKE eingeplant, wurde
aber im Projekt aus Kostengründen dann nicht realisiert. In allen drei Pilotprojekten waren wiederum die Ebenen der betrieblichen Informationssysteme (vor
allem ERP-Systeme) und die Datenebene (vor allem Datenbanken) von der
Integration betroffen.
Abbildung 64: Einbettung der Pilotprojekte in den Bezugsrahmen (eigene Darstellung)
Die besondere Herausforderung im Vorgehen und Projektmanagement lag bei allen
drei Projekten in einer partizipativen Vorgehensweise mit begleitenden Projektmarketing-Aktivitäten. Daher waren auch die Erkenntnisse aus der Anwendung einzelner
Methoden und Werkzeuge in den Unternehmen sehr wertvoll und flossen im Zuge
der mehrfachen Verfeinerung in das Vorgehensmodell ein. Die Pilotprojekte machten
deutlich wie wichtig es ist, die Stakeholder von Beginn an in das Projektgeschehen
zu involvieren. Durch die Anwendung der beschriebenen Methoden bzw. Werkzeuge
in den Projekten wurde die Partizipation aller Beteiligten sichergestellt. Dies war
ein wesentlicher Erfolgsfaktor, in dem sich das entwickelte Vorgehensmodell auch
von bestehenden Modellen unterscheidet617.
Die Projekte mit Teufelberger und NKE waren zeitlich die ersten beiden und wurden
nahezu parallel durchgeführt. Danach wurden wesentliche Erkenntnisse in das
617
Siehe dazu auch das Kapitel zu den Anforderungen an das Vorgehensmodell (Kapitel 5.5).
227
Modell aufgenommen. Mit der Durchführung des dritten Pilotprojekts mit Fronius hat
das Vorgehensmodell bereits mehrere Schritte der Konsolidierung durchlaufen. Die
Anwendung bei Fronius brachte keine wesentlichen Änderungen mehr mit sich. Die
Durchführung von drei Pilotprojekten zeigte die praktische Anwendbarkeit des
Vorgehensmodells im inner-, über- und zwischenbetrieblichen Kontext. Damit
gilt die wissenschaftliche Fragestellung (FS6) als beantwortet.
228
Reflexion
9 Reflexion
Im abschließenden Kapitel werden nun nochmals die zentralen Ergebnisse und
Schlussfolgerungen zusammengefasst und kritisch gewürdigt618. Zuletzt wird ein
Ausblick auf weitere Forschungstätigkeiten gegeben.
9.1 Zusammenfassung der zentralen Ergebnisse
Das primäre Ziel der Arbeit ist es, ein wissenschaftlich fundiertes Vorgehensmodell
zur Einführung von betrieblichen Integrationslösungen zu entwerfen, das den Anforderungen gängiger Unternehmenspraxis entspricht. Der gewählte Forschungsansatz
ist der gestaltungsorientierten bzw. konstruktivistischen Wirtschaftsinformatik619 zuzuordnen. Die Forschungsarbeit zur Beantwortung der Forschungsfragen
verlief dabei in mehreren Iterationen in den vier Phasen Analyse, Entwurf, Evaluation und Diffusion620.
Die erste Forschungsphase, die Analyse, umfasste vier Teile: eine Literaturrecherche
zu den Grundlagen betrieblicher Integration, eine explorative Studie, eine Literaturrecherche zu Vorgehensmodellen und eine Analyse von Fallstudien. Zu den wesentlichen Ergebnissen der vorliegenden Arbeit zählt die Herleitung eines Bezugsrahmens, bestehend aus drei Integrationsdimensionen und fünf Integrationsebenen.
Technologie, Organisation (inner-, über- und zwischenbetrieblich) und betriebliches
Umfeld (Rahmenbedingungen) bezeichnen dabei die Integrationsdimensionen.
Ferner zeigen die Integrationsebenen, dass eine betriebliche Integration auf Ebene
der Daten, auf Ebene der betrieblichen Informationssysteme, durch den Einsatz
von dedizierter Software als „Middleware“, auf der sozialen Ebene sowie auf
Ebene der Prozesse und Services stattfinden kann.
Durch die ergänzend durchgeführte explorative Studie konnte das Interesse und die
Relevanz betrieblicher Integration unter österreichischen Unternehmen gezeigt
werden. Es wurde nachgewiesen, dass es auch hier Differenzen zwischen Unternehmen unterschiedlicher Größenordnung gibt. KMUs fehlt es im Gegensatz zu
Großunternehmen oftmals an Know-How und schriftlichen Strategien bzw. Richtlinien
im IT-Bereich. Auch ist der Durchdringungsgrad an betrieblichen Informationssystemen im Vergleich zwischen großen und kleineren Unternehmen bei Großunternehmen signifikant höher. Die Hauptgründe für die Durchführung einer betrieblichen
618
619
Vgl. Österle et al. (2010); Hevner et al. (2004)
620
Reflexion
229
Integration werden generell in der „Beschleunigung von Geschäftsprozessen“, gefolgt von „Kostensenkungen“ und „Qualitätsverbesserungen“ sowie „Produktivitätsverbesserungen“ gesehen.
Der dritte Teil der Analyse befasste sich mit Vorgehensmodellen in der Literatur. Die
durchgeführte Literaturrecherche machte deutlich, dass Vorgehensmodelle aufgrund
der Komplexität von Integrationsprojekten sinnvoll und auch notwendig sind. Es
konnte gezeigt werden, dass sich gängige Vorgehensmodelle gut vergleichen lassen.
Obwohl Anzahl der Phasen und deren Bezeichnungen variieren konnte ein allgemeines Grundmuster aus „Orientierung“, „Analyse“, „Design“, „Realisierung“
und „Betrieb“ abgeleitet werden.
Im vierten Teil der Analysephase wurden drei Fallstudien nach einer gemeinsamen Methode erhoben und ein Fallstudienvergleich durchgeführt. Die Fallstudien behandeln individuelle, nachhaltige Integrationslösungen und die angewandten
Konzepte, Technologien und Standards bei der Umsetzung auf unterschiedlichen
Ebenen. Für den Vergleich wurde einerseits der in den Grundlagen erarbeitete
Bezugsrahmen herangezogen, andererseits wurde das Vorgehen bei der Umsetzung
der Integrationslösung analysiert. Aus Sicht des Bezugsrahmens war festzustellen,
dass sowohl in den wissenschaftlichen Ansätzen, als auch in den Beispielen aus der
Wirtschaft eine Lücke auf der Unterstützung der sozialen Ebene besteht. Durch
die Betrachtung der Vorgehensweise bei der Umsetzung konnte ein gemeinsames
Vorgehen in den Fallstudien identifiziert werden. Weiters zeigte sich auch hier,
dass Bedarf in der methodischen Vorgehensweise besteht. Die Fallstudien haben
offengelegt, dass vor allem in den Phasen „Analyse“ und „Design“, aber auch in der
Evaluierung Unterstützungsbedarf besteht, da diese aufgrund des Fehlens einer
Methodik nur unvollständig durchgeführt wurden.
Die zentralen Ergebnisse aus der Analysephase bildeten den Ausgangspunkt für
einen ersten Entwurf des Vorgehensmodells. Die erste Modellbildung fokussierte
auf einzelne Aktivitäten und erzielten Resultate aus den Fallstudien in den zuvor
hergeleiteten Phasen und Aspekten aus der Literatur. Dieses erste Vorgehensmodell
wurde für die Durchführung von Pilotprojekten herangezogen.
In der dritten Forschungsphase wurde die Praxistauglichkeit des Vorgehensmodells über drei Pilotprojekte evaluiert und das Modell iterativ konsolidiert. Dazu
wurde der Entwurf des Vorgehensmodells in den ersten beiden Pilotprojekten als
Grundgerüst für ein strukturiertes Vorgehen verwendet. Durch die Anwendung in der
Praxis konnten die jeweiligen Aktivitäten mit konkreten Methoden und Werkzeugen
hinterlegt und das Modell verfeinert werden. Die Durchführung eines dritten Pilotprojektes brachte keine wesentlichen Änderungen im Vorgehensmodell mehr mit sich.
Eine Betrachtung im Bezugsrahmen zeigt, dass die Pilotprojekte alle drei Integrati-
230
Reflexion
onsdimensionen und auch die Integrationsebenen abdeckten. Zwei der Projekte
befassten sich intensiv mit Konzepten und Technologien zur Integration auf der
sozialen Ebene und in allen drei Projekten waren die Ebene der Prozesse und Services, die Ebene der betrieblichen Informationssysteme und die Datenebene betroffen. Auch die Ebene der Middleware war in einem Pilotprojekt eingeplant, wurde im
Projektverlauf aber aus Kostengründen nicht realisiert.
Beachtung fand auch die vierte Forschungsphase, die sich mit der Diffusion von
Ergebnissen und Teilergebnissen auseinandersetzte. Neben populärwissenschaftlichen Veröffentlichungen waren es vor allem die Einreichungen auf wissenschaftlichen Konferenzen und Journalen, die wertvolles Feedback und Einblick zum internationalen Stand der Forschung lieferten. Folgende Veröffentlichungen konnten zum
Erkenntnisgewinn in der gegenständlichen Arbeit beitragen:

Der erste Forschungsansatz und mögliche anzuwendende Methoden
wurden bereits Ende 2007 bzw. Anfang 2008 auf zwei internationalen Konferenzen zur Diskussion gestellt621. Ein erweiterter Forschungsansatz wurde im
darauffolgenden Jahr auf einer internationalen Konferenz platziert622. Auch auf
dieser Konferenz wurde in einer ersten Fassung ein Teil des Bezugsrahmens,
nämlich die Betrachtung von betrieblicher Integration auf unterschiedlichen
konzeptuellen Ebenen, vorgestellt623. Zusätzlich wurde ein deutschsprachiger
Buchbeitrag mit den Möglichkeiten der betrieblichen Integration in Wertschöpfungsnetzwerken verfasst624.

Neben den methodisch orientierten Beiträgen gab es auch einige Veröffentlichungen mit speziellem Fokus. So wurde ein Beitrag zur Analyse und Software-Architektur von Integrationslösungen auf der österreichischen Fachhochschulkonferenz veröffentlicht625. Das Vorgehen bei Integrationsprojekten
mit Blick auf die soziale Ebene wurde in drei unterschiedlichen Konferenzbeiträgen im Jahr 2011 thematisiert. Hierin befanden sich auch erste Ergebnisse
aus den Fallstudien bzw. Pilotprojekten626. Die Dokumentation des Pilotprojektes mit Teufelberger ist als eigene Fallstudie als Buchbeitrag erschienen627.
Ein weiterer Beitrag thematisierte den kombinierten Einsatz mehrerer Metho-
621
Vgl. Auinger und Nedbal (2007), (2008)
622
Vgl. Auinger und Nedbal (2009)
623
624
Vgl. Nedbal und Auinger (2010a)
625
626
Vgl. Auinger et al. (2011a), (2011b), (2011c)
627
Reflexion
231
den (Eye-Tracking, heuristische Evaluierung und Feedback-Blog) bei der Evaluierung von Integrationslösungen628. Und zusätzlich war ein Beitrag auf die
Erfolgsfaktorenanalyse als Analysemethode gerichtet629.

Das Vorgehensmodell in einer fortgeschrittenen Fassung wurde in der
deutschsprachigen Zeitschrift „HMD – Praxis der Wirtschaftsinformatik“ mit einer Fallstudie als Praxisbeispiel veröffentlicht630. Zusätzlich wurde das Vorgehensmodell auf einer internationalen Konferenz vorgetragen631. Im Zuge der
Konferenzteilnahme wurde dieser Beitrag auch in einer überarbeiteten und
erweiterten Fassung für eine Journalpublikation eingeladen. Die akzeptierte
Fassung erschien nun Anfang 2013 im International Journal of Services, Economics and Management (IJSEM)632.
Aktuelle Möglichkeiten zur Durchführung individueller inner-, über- und zwischenbetrieblicher Integration wurden analysiert, in einem generischen Vorgehensmodell
konsolidiert, dieses Modell wurde bezüglich seiner praktischen Anwendbarkeit in
Pilotprojekten erprobt und Teilergebnisse aus diesem Forschungsprozess wurden
veröffentlicht. Das zentrale Ergebnis aus den vier Forschungsphasen ist daher
ein wissenschaftlich fundiertes und praktisch erprobtes Vorgehensmodell zur
betrieblichen Integration.
9.2 Kritische Würdigung
Die Forschungsmethodik zur Erzielung der Ergebnisse bediente sich vorwiegend
Methoden der qualitativen Forschung. Durch die Anwendung des Prinzips der Triangulation wurde das Forschungsphänomen der betrieblichen Integration mit mehreren
Quellen und Methoden gegengeprüft, was auch das Vertrauen in die wissenschaftlichen Erkenntnisse gestärkt hat633. Die Anwendung eines Methoden-Mix aus mehreren Forschungsmethoden gibt allerdings auch mehrere Möglichkeiten zur Kritik. Die
erste Einschränkung ergibt sich aus der Tatsache, dass sich auch durch Triangulationen die Validität nicht eindeutig überprüfen lässt. Das Ziel konnte daher auch nur
die Konstruktion von Wissen, also die Validierung und nicht die Herstellung von
Validität sein634. Die Vertrauenswürdigkeit in die wissenschaftlichen Ergebnisse
628
Vgl. Auinger et al. (2011d)
629
Vgl. Nedbal et al. (2012a)
630
Vgl. Nedbal et al. (2012b)
631
Vgl. Nedbal (2011)
632
Vgl. Nedbal (2013)
633
Vgl. Malhotra und Grover (1998, S. 410)
634
Vgl. Lamnek (2005, S. 165)
232
Reflexion
wurde auch durch die Forschungsdauer von mehr als fünf Jahren, persönliches
Engagement, die nachvollziehbare Dokumentation des Forschungsprozesses und
die zusätzliche Validierung der Ergebnisse in Pilotprojekten erhöht635.
Ein nahezu ständiger Begleiter im Forschungsprozess war die Literaturrecherche.
Aus zeitlicher Sicht startete diese bereits zu Beginn der Forschungstätigkeit. Aufgrund der Aktualität der Thematik wurden die wissenschaftlichen Quellen auch immer
wieder auf neue Arbeiten durchsucht. So wurden Veröffentlichungen bis Ende 2012
in der Arbeit berücksichtigt und das Delta mehrmals eingearbeitet. Die Literaturrecherche gestaltete sich alleine aufgrund der unterschiedlichen Verwendung des
Begriffs „betriebliche Integration“ nicht einfach636. Auch die Literaturrecherche nach
Vorgehensmodellen förderte viele relevante Modelle zutage. Trotz sorgfältiger Recherche ist dem Autor bislang jedoch kein spezifisches Vorgehensmodell für die
betriebliche Integration bekannt, das die in Kapitel 5.5 gestellten Anforderungen
abdeckt.
Klaren Einschränkungen unterliegt die empirische Erhebung aufgrund der Stichprobengröße und der Anzahl an gültigen Antworten. Trotz der geringen Rücklaufquote
und den damit verbundenen Problemen, die Relevanz der quantitativen Forschungsarbeit zu rechtfertigen, lässt die Studie aber auch einige Tendenzen erkennen.
Gezeigt wurde unter anderem, dass österreichische KMUs durch fehlendes KnowHow und Strategieorientierung einen Nachholbedarf gegenüber Großunternehmen
haben. Die Erhebung wurde in einer frühen Phase der Forschungsarbeit als explorative Studie durchgeführt und sollte dahingegen auch nur als zusätzliche, ergänzende
Methode in der Erforschung des Forschungsfeldes gesehen werden.
Wie auch bereits einleitend klargestellt, kommen Fallstudien in der Wirtschaftsinformatikforschung häufig zum Einsatz637. Ein häufiger Kritikpunkt an Fallstudien im
Allgemeinen ist die Generalisierbarkeit der Ergebnisse638. Dieser Kritikpunkt trifft
auch aufgrund der geringen Anzahl an erhobenen Fällen für die gegenständliche
Forschungsarbeit zu. Auch wurden nur österreichische Unternehmen in die Studien
einbezogen, was auf der anderen Seite klar das Zielgebiet der Untersuchung war.
Ferner wurden die Fallstudien im Nachhinein aufgenommen, dh. die betriebliche
Integration war zum Zeitpunkt der Erhebung der Fallstudie bereits abgeschlossen.
Die Einführung der Integrationslösung wurde von den Forschenden also nicht aktiv
begleitet. Bei diesen zurückblickenden Betrachtungen ist man von der Verfügbarkeit
635
Vgl. Lamnek (2005, S. 161)
636
Siehe dazu das Kapitel 3.1 mit den Begriffsbestimmungen und der Abgrenzung.
637
Siehe dazu Kapitel 2.2.3
638
Vgl. Chan und Swatman (2002)
Reflexion
233
von Dokumentationen bzw. dem korrekten Erinnerungsvermögen der Interviewten
abhängig. Es besteht daher die Gefahr, dass wichtige bzw. zufällige Aspekte vergessen wurden639. Positiv ist in diesem Zusammenhang anzumerken, dass nicht nur
Fallstudien retrospektiv erhoben wurden, in denen man auf die Angaben externer
Personen angewiesen war, sondern auch Pilotprojekte mit aktiver Beteiligung durchgeführt wurden. Die Anwendung des Vorgehensmodells im Unternehmenskontext
wurde mehrfach durchgeführt, sodass eine Evaluation im Feld anhand mehrerer
Beispiele gezeigt werden konnte.
Sowohl die Fallstudien als auch die Pilotprojekte behandelten ausschließlich Fälle
von erfolgreichen Integrationslösungen. Dies zeigt zwar, dass das erstellte Vorgehensmodell in der Praxis erfolgreich angewendet werden kann, führt jedoch auch zu
einer gewissen Verzerrung und Voreingenommenheit640. Eine Analyse abweichender
Fälle - also fehlgeschlagener betrieblicher Integrationslösungen - würde die Validierung der Ergebnisse verbessern. Trotz vielen möglichen negativen Beispielen von
Integrationsprojekten ist es sehr schwer, diese in der Wirtschaft zu finden, da Unternehmen diese ungern weitergeben und auch nicht veröffentlicht haben wollen. Das
führte auch in dieser Arbeit dazu, dass die Fallbeispiele nur erfolgreiche Integrationslösungen zeigen. Trotzdem hatte sich vor allem in den Pilotprojekten herausgestellt,
wo mögliche Widerstände und die Bedenken verschiedener Stakeholder liegen.
Methoden wie die Stakeholderanalyse oder Erfolgsfaktorenanalyse sind geeignet,
diese latenten Widerstände aufzudecken, um in der Folge Gegenmaßnahmen einleiten zu können.
Eine weitere Einschränkung gibt es hinsichtlich der verwendeten Technologie. In
allen drei Pilotprojekten kam für die Umsetzung Microsoft Sharepoint 2010 zum
Einsatz. Dies lag daran, dass in den Unternehmen Software von Microsoft bereits in
Verwendung war und als Voraussetzung für die spätere Implementierung vorgegeben wurde. In der partizipativen Erhebung der Anforderungen in der Analysephase
der Projekte wurde bewusst immer die Technologie ausgeblendet und betont, dass
nicht das spätere Werkzeug, sondern nur das Konzept zur Unterstützung der Arbeitsweisen im Vordergrund steht.
Auch hinsichtlich der partizipativen Entwicklung gilt es einige Einschränkungen
anzumerken. Die verwendeten Methoden im Vorgehensmodell zielen stark auf Partizipation als wesentlichen Erfolgsfaktor ab. Hierin besteht die Gefahr, dass durch
Partizipation ab einem gewissen Punkt keine grundlegenden Probleme mehr erkannt
639
Vgl. Rogers (2003, S. 163–164)
640
Vgl. Rogers (2003, S. 106–118)
234
Reflexion
werden641. Diese Einschränkung hängt auch mit der verwendeten Technologie zusammen. Nutzer sowie Entwickler könnten sich damit abfinden, dass es „nicht anders
geht“ und eine Art „Betriebsblindheit“ entsteht. Problematisch bei der partizipativen
Vorgehensweise kann auch die Zahl der Wünsche sein, die es zu berücksichtigen
gilt. Wenn diese nicht mehr in angemessener Zeit abgearbeitet werden können,
besteht die Gefahr, dass sich die involvierten Nutzer nicht ernst genommen fühlen.
Als Folge werden die Wünsche, Anregungen sowie Fehler nicht mehr bekanntgeben,
das System kann nicht geeignet verbessert werden und wird nicht akzeptiert. Abhilfe
kann die Einschränkung der Beta-Phase auf eine überschaubare Anzahl an Nutzern
schaffen. Als Werkzeugunterstützung bietet sich die Verwendung eines FeedbackBlogs an, in dem zumindest ein aktueller Status zu jedem Punkt abgerufen werden
kann.
Ob mit dem Vorgehensmodell in der breiten Praxisanwendung effektiv die postulierten Resultate erzielt werden können, werden die zukünftige Forschung sowie weitere
Erfahrungen in der Praxis zeigen müssen.
9.3 Ausblick
Aus der vorliegenden Arbeit gibt es aufgrund der Veränderungen in der Organisation
und ihrer Umwelt sowie durch neue Technologien eine Reihe möglicher Anknüpfungspunkte für weitere Forschung. Diese drei Integrationsdimensionen werden auch
in der Zukunft relevante Konzepte auf unterschiedlichen Integrationsebenen hervorbringen, die eine Veränderung der betrieblichen Integrationslösungen erforderlich
machen oder neue innovative Lösungen erzeugen. Die Bereitstellung einer geeigneten Methodik zur effizienten und effektiven Einführung betrieblicher Integrationslösungen wird daher – wie bereits in der Vergangenheit - auch in Zukunft Beachtung
finden.
Vor allem die beiden Praxisprojekte, die sich mit Konzepten und Technologien auf
der sozialen Ebene befassten, konnten methodisch einige Lücken in der Einführung
von Enterprise 2.0 schließen und zur Konsolidierung des Vorgehensmodells wesentlich beitragen. In diesem Zuge wurden Anwendungsszenarien wie das Konzept der
Innovationsnetzwerke umgesetzt642. Um den wirtschaftlichen Erfolg nachhaltig zu
sichern, haben Unternehmen nun damit begonnen, diese Konzepte und Technologien als Treiber von Innovationen zu verwenden643. Klassische betriebliche Informationssysteme, wie beispielsweise ERP-Systeme, decken diesen Innovationsprozess
641
Vgl. Zinkernagel (2001)
642
Siehe Pilotprojekt 3 (Kapitel 8.4)
643
Vgl. Bughin et al. (2008, S. 10); Kranz et al. (2009)
Reflexion
235
nicht geeignet ab. Sie wirken eher hemmend, da sie den Spielraum für die Innovationsleistung einschränken. Notwendig ist eine Einbeziehung externer Quellen in den
Innovationsprozess644. Dabei sind es gerade die frühen Phasen des Innovationszyklus und die Unterstützung von Open Innovation Strategien, die zielgerichtet durch
Enterprise 2.0 unterstützt werden können645. Hier müsste im Detail untersucht werden, wie eine innovationsfreudige Umgebung im Unternehmen geschaffen werden
kann, um gerade diese frühen Phasen im Innovationsprozess ganzheitlich unterstützen zu können. Dies könnte den Integrationsbedarf bestimmen und entscheidend für
eine Umsetzung von Open Innovation sein. Dementsprechend müsste auch das
Vorgehensmodell geprüft und erweitert werden.
Eine Facette, die auch bereits im Kontext der Arbeit untersucht wurde, jedoch noch
weiterer Forschung bedarf, ist die der ökologischen Nachhaltigkeit von betrieblichen
Integrationslösungen. Bedingt durch die Tatsache, dass bei der Auswahl und Implementierung von Lösungsansätzen zur betrieblichen Integration meist auf die Berücksichtigung von Anforderungen der Nachhaltigkeit zur Umsetzung verzichtet wird646,
bietet sich noch viel Potenzial zur Verbesserung der Energieeffizienz in der gesamten Wirtschaft. Den Analysten von A.T. Kearney zufolge produzierte die IT im Jahr
2008 bereits 600 Millionen Tonnen CO2 Ausstoß pro Jahr. Das ist in etwa so viel wie
320 Millionen Kleinwagen647. Eine Gartner Studie kam zu der Erkenntnis, dass sich
die IT bereits für ca. 2% des globalen CO2 Ausstoßes verantwortlich zeichnet, was in
etwa gleich viel ist wie die gesamte Luftfahrt648. Mehrere Initiativen auf regionaler,
nationaler und internationaler Ebene haben damit begonnen, dieses gesellschaftlich
wichtige Thema aufzugreifen und Unternehmen müssen sich auch auf staatliche
Vorschriften einstellen649. In einer Mitteilung der EU-Kommission wird dargelegt, dass
es hauptsächlich darauf ankommt „strukturelle Veränderungen anzuregen, die darauf
gerichtet sind, das Potenzial der IKT zur Verbesserung der Energieeffizienz in der
gesamten Wirtschaft auszuschöpfen, z. B. durch Einsatz der IKT in Geschäftsprozessen, Ersetzung materieller Produkte durch Online-Dienstleistungen (‚Dematerialisierung‘), Verlagerung von Geschäftsvorgängen ins Internet (Banken, Immobilien)
und Einführung neuer Arbeitsweisen (Video- und Telefonkonferenzen)“650. Damit
644
Vgl. Sommerlatte (2005, S. 1684)
645
Vgl. Gassmann und Enkel (2006); Reichwald und Piller (2006)
646
Siehe Ergebnisse der explorativen Studie (Kapitel 4.2.7). Demnach besteht der Hauptgrund für die
Durchführung einer betrieblichen Integration in der „Beschleunigung von Geschäftsprozessen“, gefolgt
von „Kostensenkungen“, „Qualitätsverbesserungen“, „Produktivitätsverbesserungen“ und „Anpassung
an Kundenwünsche“.
647
Vgl. Haas und Jamjoum (2008, S. 3)
648
Vgl. Gartner (2007)
649
Vgl. Heng (2009, S. 95); Prell (2010)
650
Kommission der Europäischen Gemeinschaften (2008, S. 4)
236
Reflexion
sieht die EU-Kommission die IKT als einen wesentlichen Faktor, „der die Verbesserung der Energieeffizienz in der gesamten Wirtschaft ermöglicht, indem er neue
Geschäftsmodelle, eine bessere Überwachung und genauere Steuerung aller Arten
von Prozessen und Tätigkeiten möglich macht.“651
Das Schlagwort „Green IT“ ist vor allem der in Praktiker-Literatur der letzten Jahre
und in wissenschaftlichen Veröffentlichungen mit vorwiegend technischem Fokus zu
finden652. Eine Erweiterung in der Betrachtung von Green IT zu einer Untersuchung
auf strategischer Informationssystem-Ebene wird aktuell vor allem in der Wirtschaftsinformatik unter dem Betriff „Green IS“ intensiv diskutiert653. Diese erweiterte
Sichtweise führt dazu, dass die möglichen Maßnahmen auch mittels anderer Dimensionen bewertet werden müssen. Dadurch entstehen erweiterte Handlungsfelder mit
neuen Lösungsansätzen654, Theorien, konzeptuelle Modelle und Vorgehensmodelle655 sowie Geschäftsmodelle656, die hohe Potenziale zur Verbesserung der Energieeffizienz aufweisen, jedoch aus wissenschaftlicher Sicht noch unzureichend untersucht wurden. Als Teil des Forschungsprojekts 4EMOBILITY657 konnte im Zuge der
Arbeiten an der gegenständlichen Dissertation auch der Beitrag betrieblicher Integrationslösungen zur Verbesserung der Energieeffizienz auf unterschiedlichen Integrationsebenen untersucht werden. Hier zeigte sich, dass sich die in dieser Arbeit hergeleiteten fünf konzeptuellen Ebenen der Integration geeignet sind, Integrationslösungen unter dem Gesichtspunkt der Energieeffizienz zu beschreiben. Der
Bezugsrahmen ist jedoch um eine vierte Integrationsdimension, die Ökologie, zu
erweitern. Ergebnisse daraus mit speziellem Fokus auf „Green IS“ mündeten in
mehreren wissenschaftlichen Veröffentlichungen658.
651
Kommission der Europäischen Gemeinschaften (2008, S. 4)
652
Vgl. Lorenz (2008); Mey (2010); Marcais (2008); Bachour und Chasteen (2010, S. 1); Mingay
(2007, S. 1); Vykoukal et al. (2009, S. 1); Verheyen (2008); Wengorz (2008, S. 42); Bazzanella (2008,
S. 46); Samson (2007, S. 1)
653
Vgl. Watson et al. (2010, S. 23); Bengtsson und Agerfalk (2011, S. 4); Elliot (2007, S. 109); Elliot
und Binney (2008); Erek et al. (2010, S. 18); Murugesan (2008, S. 24); Loos et al. (2011, S. 239);
Molla (2009, S. 3), (2008); Molla et al. (2008, S. 671); Molla et al. (2011, S. 71); Butler (2011, S. 1);
Dao et al. (2011, S. 1); Ijab et al. (2010, S. 433); Brooks et al. (2010, S. 3); Ijab et al. (2010, S. 438);
Jenkin et al. (2011, S. 18); Howard und Lubbe (2012, S. 306)
654
Vgl. Tenhunen und Penttinen (2010, S. 8); Darnall et al. (2008, S. 34); Schlieter et al. (2010); The
Boston Consulting Group (2009, S. 29); Tenhunen und Penttinen (2010, S. 8)
655
Vgl. Elkington (2004); Overby (2008, S. 288); Sarkis et al. (2011); Schmidt et al. (2009, S. 1)
656
Vgl. Lee und Casalegno (2010); Babin und Nicholson (2009); Orsato (2006, S. 131)
657
Siehe auch Vorwort. Das Projekt 4EMOBILITY wurde im Rahmen des EU-Programms „Regionale
Wettbewerbsfähigkeit OÖ 2007-2013 (Regio 13)“ aus Mitteln des Europäischen Fonds für Regionale
Entwicklung (EFRE) sowie aus Landesmitteln gefördert.
658
Vgl. Nedbal und Auinger (2010b); Nedbal et al. (2011); Nedbal et al. (2012c); Nedbal und Wetzlinger (2012); Nedbal (2012)
Reflexion
237
Aus der Betrachtung zur Energieeffizienz heraus hat sich gezeigt, dass vor allem
Konsolidierungsmaßnahmen und die damit verbundenen Kosteneinsparungen durch
Virtualisierung einen wesentlichen Einflussfaktor für Green IS darstellen659. Virtualisierung bzw. Cloud Computing660 sind dabei die Technologien, welche aufgrund
effizienterer Nutzung der Hardware eine Verbesserung der Energieeffizienz mit sich
bringen. Cloud Computing hat nicht nur Potential zur Effizienzsteigerung, sondern
damit einhergehend auch Potential zur Reduktion von Umweltbelastungen durch
Verringerung im Ressourcenverbrauch661. Durch die Transparenz gegenüber den
Endnutzern birgt Cloud Computing gleichzeitig aber auch die Gefahr der Verschwendung von Ressourcen, sodass die Einsparungen auch negativ wirken können662.
Dieses aus technischer Sicht evolutionäre, aber aus Sicht des Geschäftsmodells
revolutionäre Konzept des Cloud Computing wird das Verständnis über die Entwicklung, Integration, Bereitstellung und Nutzung von IT-Dienstleistungen in den nächsten Jahren maßgeblich beeinflussen663. Wissenschaft und Praxis sind daher gleichermaßen gefordert, sich mit dieser neuen Technologie auseinanderzusetzen. Vor
allem für die Wirtschaftsinformatik ist eine ganzheitliche Betrachtung unterschiedlicher Cloud Infrastrukturen für den optimalen Unternehmenseinsatz Gegenstand
weiterer Forschung. Die mit Cloud Computing verbundenen wissenschaftstheoretischen Grundlagen aus ökonomischen, sozialen, organisatorischen sowie
ökologischen Gesichtspunkten sind ebenso zu erforschen wie mögliche technische
Optimierungsmöglichkeiten, um Cloud-Lösungen im interdisziplinären Einsatz optimal
gestalten zu können. Mit dem Projekt „OptiCloud“664 konnte ein Forschungsprojekt
erfolgreich platziert werden, welches sich die nächsten Jahre mit diesen Gesichtspunkten auseinandersetzen wird. Erweiterungspotential hinsichtlich des in dieser
Arbeit entwickelten Bezugsrahmens sowie des Vorgehensmodells besteht durch die
erweiterten Möglichkeiten der Integration, die durch eine bedarfsgerechte Nutzung
externer Hard- und Software ermöglicht werden. Diese sind im Zuge der Analyse
(Phase 2 des Vorgehensmodells) sowohl aus organisatorischer (z.B. Erweiterung der
Stakeholderanalyse), prozessorientierter (z.B. Outsourcing von Geschäftsprozessen
an Cloud Computing Anbieter) und technischer Sicht (z.B. Beurteilung der eigenen
Infrastruktur und Vergleich mit Cloud Computing Anbietern) zu bewerten. Damit soll
659
Vgl. Molla et al. (2009, S. 22); Moghaddam et al. (2011, S. 259)
660
Vgl. Dillon et al. (2010); Lorenz (2008, S. 85)
661
Vgl. Bose und Luo (2011, S. 5)
662
Vgl. Atkinson et al. (2011, S. 519); Shrake et al. (2011, S. 6)
663
Vgl. Stemmer et al. (2011, S. 6); Baun et al. (2011, S. 242)
664
Das Projekt „OptiCloud - Interdisziplinäre Betrachtung und Gestaltung von optimalen ‚Private
Clouds‘ für den Unternehmenseinsatz“ wurde im Rahmen des EU-Programms „Regionale Wettbewerbsfähigkeit OÖ 2007-2013 (Regio 13)“ aus Mitteln des Europäischen Fonds für Regionale Entwicklung (EFRE) sowie aus Landesmitteln gefördert.
238
Reflexion
geprüft werden, wie diese neuen Konzepte und Technologien aus dem Cloud Computing Umfeld665 in das erstelle Vorgehensmodell eingebunden werden können.
In diesem Sinne wäre es vorteilhaft, wenn das Vorgehensmodell um wissenschaftliche Erkenntnisse ergänzt und in weiteren Praxisanwendungen geprüft wird. Gegebenenfalls sind Aktivitäten, Methoden und Werkzeuge zu ergänzen oder bestehende
zu optimieren. Dies würde das Vorgehensmodell weiter validieren und die Vertrauenswürdigkeit steigern. Zusätzlich könnte ein Werkzeug zur Unterstützung im Projektmanagement für das Vorgehensmodell entworfen und dieses bei der Einführung
betrieblicher Integrationslösungen mehrfach angewendet werden.
665
In Fallstudie 2 (siehe Kapitel 6.3) wurde mit SaaS bereits ein Konzept im Umfeld des Cloud Computing behandelt.
Literaturverzeichnis
239
Adam, O.; Hofer, A.; Zang, S. (2004): Unterstützung von Geschäftsprozessen in Wertschöpfungsnetzen mit Hilfe einer Architektur für kollaborative Szenarien. In: Dadam, P. und Reichert, M. (Hg.):
INFORMATIK 2004 - Informatik verbindet, Band 2, Beiträge der 34. Jahrestagung der Gesellschaft
für Informatik e.V. (GI). 34. Jahrestagung der Gesellschaft für Informatik e.V. (GI). Ulm, 20.-24.
Sep.: GI (LNI, 51), S. 537–542.
Aier, S. (Hg.) (2006): Enterprise application integration. Serviceorientierung und nachhaltige Architekturen. 2. Aufl. Berlin: Gito-Verl.
Alavi, M. (1984): An assessment of the prototyping approach to information systems development. In:
Commun. ACM 27 (6), S. 556‐563.
Alloway, R. M. (1980): Defining success for data processing: a practical approach to strategic planning
for the DP department: Center for Information Systems Research, MIT.
Alt, R.; Betts, R.; Grünauer, K. M.; Klüber, R.; Schelhas, K.-H. (2000a): Towards a Method for Business Networking. In: Österle, H., Fleisch, E. und Alt, R. (Hg.): Business Networking - Shaping Collaboration Between Enterprises. 2. Aufl. Berlin: Springer, S. 265–288.
Alt, R.; Fleisch, E. (2003): Netzwerkfähigkeit von Unternehmen: Beiträge des Business Engineering
zum Business Networking. In: Österle, H. und Winter, R. (Hg.): Business Engineering. Auf dem
Weg zum Unternehmen des Informationszeitalters. 2. Auflage. Berlin: Springer, S. 353-369.
Alt, R.; Fleisch, E.; Österle, H. (2000c): Introduction – Chances and Challenges in Business Networking. In: Österle, H., Fleisch, E. und Alt, R. (Hg.): Business Networking - Shaping Collaboration Between Enterprises. 2. Aufl. Berlin: Springer, S. 1–14.
Alt, R.; Österle, H. (2000): Services als neue Herausforderung im Business Networking. In: IM Information Management & Consulting 2.
Amer-Yahia, S.; Kotidis, Y. (2004): A Web-Services Architecture for Efficient XML Data Exchange. In:
Data Engineering, International Conference on, S. 523–534.
Anstett, T.; Leymann, F.; Mietzner, R.; Strauch, S. (2009): Towards BPEL in the Cloud: Exploiting
Different Delivery Models for the Execution of Business Processes. In: World Conference on Services - I, S. 670–677.
Ardagna, D.; Baresi, L.; Comai, S.; Comuzzi, M.; Pernici, B. (2011): A Service-Based Framework for
Flexible Business Processes. In: Software, IEEE 28 (2), S. 61–67.
Arend-Fuchs, C.; Bielert, P. (2009): Ready for Value chain competition. Neue Geschäftsmodelle durch
Prozessintegration. In: HMD - Praxis der Wirtschaftsinformatik (266), S. 63–70.
Ash, C. G.; Burn, J. M. (2003): A strategic framework for the management of ERP enabled e-business
change. In: European Journal of Operational Research 146 (2), S. 374‐387.
Atkinson, C.; Schulze, T.; Klingert, S. (2011): Modelling as a Service (MaaS): Minimizing the Environmental Impact of Computing Services. In: IEEE World Congress on Services (SERVICES), S. 519–
523.
Auinger, A.; Hochmeier, A.; Nedbal, D. (2011a): An Approach For Implementing Enterprise 2.0
Platforms: Methodology And Selected Results Of Pilot Projects. In: Proceedings of the IADIS International Conference on Information Systems 2011 (IS 2011). Avila, Spain, S. 179–185.
Auinger, A.; Hochmeier, A.; Nedbal, D. (2011b): Cross-Organizational Enterprise 2.0 Projects as a
door opener for Open Ecosystems. In: Proceedings of the International InCo Conference. Ljubljana, Slovenia, S. 1–6.
Auinger, A.; Hochmeier, A.; Nedbal, D. (2011c): Organization-driven Approach for Enterprise 2.0
Projects. In: Tagungsband FFH 2011 (5. Forschungsforum der österreichischen Fachhochschulen).
Wien, Austria, S. 136–139.
Auinger, A.; Lechner, M.; Nedbal, D. (2010): Supply Chain Information Management mittels Enterprise
2.0: Analyse und Software-Architektur. In: Tagungsband des 4. Forschungsforum der österreichischen Fachhochschulen (FFH). Pinkafeld, Austria, S. 91–97.
240
Auinger, A.; Nedbal, D. (2007): GuideBIS - Guidance Model for Business Integration Solutions. In:
Proceedings of the IADIS International Conference on e-Commerce 2007 (EC2007). International
Conference on e-Commerce 2007. Algarve, Portugal. IADIS, S. 271–275.
Auinger, A.; Nedbal, D. (2008): Towards a Guidance Model for Business Integration Solutions. In:
Proceedings of the International Joint Conference on e-Commerce e-Administration, e-Society and
e-Education (e-CASE), Bangkok, Thailand, S. 1–16.
Auinger, A.; Nedbal, D. (2009): Effective Supply Chain Information Management in Supply Networks
using Enterprise 2.0. In: Proceedings of the 2009 International Conference on e-Learning, eBusiness Enterprise Information Systems, and e-Government (EEE‘09), S. 213–217.
Auinger, A.; Nedbal, D.; Hochmeier, A.; Holzinger, A. (2011d): User-Centric Usability Evaluation For
Enterprise 2.0 Platforms: A complementary multi-method approach. In: Proceedings of the International Conference on e-Business (ICE-B 2011). Sevilla, Spain, S. 119–124.
Auinger, A.; Nedbal, D.; Kirchberger, H. (2012): Einführung des "Intranet T2.0" bei der Teufelberger
GmbH. In: Back, A., Gronau, N. und Tochtermann, K. (Hg.): Web 2.0 in der Unternehmenspraxis.
Social-Media-Grundlagen und -Trends sowie Methoden und Fallstudien zu Enterprise 2.0. 3., vollständig überarbeitete Auflage. München: Oldenbourg, S. 1–12.
Auinger, A.; Nedbal, D.; Wöß, W. (2009): A Holistic Approach for B2B Integration at Different Conceptual Levels. In: Proceedings of the 2009 International Conference on e-Learning, e-Business Enterprise Information Systems, and e-Government (EEE‘09), S. 179–185.
Babin, R.; Nicholson, B. (2009): How Green is my Outsourcer - Environmental Responsibility in Global
IT Outsourcing. In: ICIS 2009 Proceedings (Paper 83), S. 1–10.
Bächle, M. (2008): Ökonomische Perspektiven des Web 2.0 - Open Innovation, Social Commerce und
Enterprise 2.0. In: Wirtschaftsinformatik 2, S. 129–132.
Bachour, N.; Chasteen, L. (2010): Optimizing the Value of Green IT Projects within Organizations. In:
IEEE Green Technologies Conference, S. 1–10.
Back, A.; Gronau, N.; Tochtermann, K. (Hg.) (2009): Web 2.0 in der Unternehmenspraxis. Grundlagen, Fallstudien und Trends zum Einsatz von Social Software. 2., aktualisierte Aufl. München:
Oldenbourg.
Back, A.; Gronau, N.; Tochtermann, K. (Hg.) (2012): Web 2.0 in der Unternehmenspraxis. SocialMedia-Grundlagen und -Trends sowie Methoden und Fallstudien zu Enterprise 2.0. 3., vollständig
überarbeitete Auflage. München: Oldenbourg.
Bagchi, P. K.; Ha, B. C.; Skjoett-Larsen, T.; Soerensen, L. B. (2005): Supply chain integration: a
European survey. In: The International Journal of Logistics Management 16 (2), S. 275–294.
Ball, M. O.; Ma, M.; Raschid, L.; Zhao, Z. (2002): Supply chain infrastructures: system integration and
information sharing. In: SIGMOD Rec. 31 (1), S. 61‐66.
Bally, L.; Brittan, J.; Wagner, K. H. (1977): A prototype approach to information system design and
development. In: Information & Management 1 (1), S. 21–26.
Banerjee, S.; Kumar, R. L. (2002): Managing electronic interchange of business documents. In:
Communications of the ACM 45 (7), S. 96‐102.
Baun, C.; Kunze, M.; Kurze, T.; Mauch, V. (2011): Private Cloud-Infrastrukturen und CloudPlattformen. In: Informatik Spektrum 34 (3), S. 242–254.
Bazzanella, H. (2008): IT-gesteuerte Energieeffizienz im Rechenzentrum. In: IM Information Management & Consulting (1), S. 46–51.
Becker, J.; Janiesch, C.; Pöppelbuß, J. (2008): Konfiguration kollaborativer Informationsmodelle. In:
Martin Bichler, Thomas Hess, Helmut Krcmar, Ulrike Lechner, Florian Matthes, Arnold Picot et al.
(Hg.): Multikonferenz Wirtschaftsinformatik, MKWI 2008, München, 26.2.2008 - 28.2.2008, Proceedings: GITO-Verlag, Berlin, S. 813–824.
Beck, K. (2000): Extreme programming eXplained. Embrace change. Reading, MA: Addison-Wesley.
Beimborn, D.; Miletzki, T.; Wenzel, S. (2011): Platform as a Service (PaaS). In: Wirtschaftsinformatik
53 (6), S. 371–375.
241
Belfo, F. (2012): People, Organizational and Technological Dimensions of Software Requirements
Specification. In: Procedia Technology 5 (0), S. 310–318.
Bengtsson, F.; Agerfalk, P. J. (2011): Information technology as a change actant in sustainability
innovation: Insights from Uppsala. In: The Journal of Strategic Information Systems In Press, Corrected Proof.
Benington, H. D. (1987): Production of large computer programs. In: Proceedings of the 9th international conference on Software Engineering. Los Alamitos, CA, USA: IEEE Computer Society Press
(ICSE ‘87), S. 299‐310.
Benlian, A.; Hess, T.; Buxmann, P. (2009): Treiber der Adoption SaaS-basierter Anwendungen - Eine
empirische Untersuchung auf Basis verschiedener Applikationstypen. In: Wirtschaftsinformatik 51
(5), S. 414–428.
Benz, A. (2009): Analyse und Verbesserung des Erfahrungstransfers bei Entwicklungsprojekten.
Diplomarbeit. Technische Universität, Graz. Institut für Industriebetriebslehre und Innovationsforschung.
Bergeron, F.; Raymond, L. (1992): The advantages of electronic data interchange. In: SIGMIS Database 23 (4), S. 19–31.
Berthon, P.; Pitt, L.; Berthon, J.-P.; Campbell, C.; Des Thwaites (2008): e-Relationships for eReadiness: Culture and corruption in international e-B2B. In: Industrial Marketing Management 37
(1), S. 83‐91.
Beynon-Davies, P. (2009): The 'language' of informatics: The nature of information systems. In:
International Journal of Information Management 29 (2), S. 92–103.
Bibikas, D.; Kourtesis, D.; Paraskakis, I. a. B. A.; Sauermann, L.; Apostolou, D. a. M. G.; Vasconcelos,
A. C. (2008): Organisational Knowledge Management Systems in the Era of Enterprise 2.0: The
case of OrganiK. In: BIS 2008 Workshop Proceedings, S. 45–53.
Biehl, M. (2007): Success factors for implementing global information systems. In: Communications of
the ACM 50 (1), S. 52–58.
Biskup, H.; Fischer, T. (1996): Vorgehensmodelle - Versuch einer begrifflichen Einordnung. Vorstellung erster Ergebnisse einer Arbeitsgruppe der Fachgruppe 5.11. Hg. v. Leitungsgremium des GIFA 5.1. Gesellschaft für Informatik. Karlsruhe. Online verfügbar unter
http://www.informatikbegriffsnetz.de/arbeitskreise/vorgehensmodelle/publikationen/bifi96.pdf, zuletzt geprüft am 01.06.2011.
Bjørn-Andersen, N. (2011): How IT will Challenge Existing Organizational Forms and Create Ambient
Organizations. In: Proceedings of the International Information Systems Conference 2011. Oman:
Sultan Qaboos University, S. 3–9.
Blair, S.; Watt, R.; Cull, T. (2010): Responsibility-Driven Architecture. In: Software, IEEE 27 (2), S. 26–
32.
Boehm, B. W. (1979): Guidelines for Verifying and Validating Software Requirements and Design
Specifications. In: Samet, P. A. (Hg.): Euro IFIP 79: North-Holland, S. 711–719.
Boehm, B. W. (1988): A Spiral Model of Software Development and Enhancement. In: Computer 21
(5), S. 61–72.
Bögli, T. (2007): Standortübergreifende Warenwirtschaft im Konsumgüterhandel. In: Wölfle, R. und
Schubert, P. (Hg.): Business Collaboration. Standortübergreifende Prozesse mit Business Software: Praxislösungen im Detail. Fallstudien, Konzepte, Modellierung. München: Hanser, S. 77–84.
Bose, R.; Luo, X. (2011): Integrative framework for assessing firms' potential to undertake Green IT
initiatives via virtualization - A theoretical perspective. In: The Journal of Strategic Information Systems In Press, Corrected Proof, S. 1–17.
Brambilla, M.; Ceri, S.; Fraternali, P.; Manolescu, I. (2006): Process modeling in Web applications. In:
ACM Trans. Softw. Eng. Methodol. 15 (4), S. 360‐409.
Breitner, M. H. (2012): Vorgehensmodell. In: Kurbel, K., Becker, J., Gronau, N., Sinz, E. und Suhl, L.
(Hg.): Enzyklopädie der Wirtschaftsinformatik – Online-Lexikon. Sechste Auflage. München:
Oldenbourg. Online verfügbar unter http://www.enzyklopaedie-der-wirtschaftsinformatik.de/, zuletzt
geprüft am 28.11.2012.
242
Brooks, S.; Wang, X.; Sarker, S. (2010): Unpacking Green IT: A Review of the Existing Literature. In:
AMCIS 2010 Proceedings, S. 1–10.
Büchner, T.; Matthes, F.; Neubert, C. (2009): A Concept and Service Based Analysis of Commercial
and Open Source Enterprise 2.0 Tools. In: International Conference on Knowledge Management
and Information Sharing. Madeira, Portugal, S. 1–9.
Bughin, J.; Manyika, J.; Miller, A. (2008): Building the Web 2.0 Enterprise: McKinsey Global Survey
Results. In: The McKinsey Quarterly (July), S. 1–10.
Burton-Jones, A.; Gallivan, M. J. (2007): Toward a Deeper Understanding of System Usage in Organizations: A Multilevel Perspective. In: MIS Quarterly 31 (4), S. 657–680.
Bussler, C. (2002): B2B Integration Technology Architecture. In: Proceedings of the 4th IEEE Int’l
Workshop on Advanced Issues of E-Commerce and Web-Based Information Systems (WECWIS
2002). 4th IEEE Int’l Workshop on Advanced Issues of E-Commerce and Web-Based Information
Systems. Los Alamitos, CA, USA. IEEE Computer Society, S. 147–152.
Bussler, C.; Fensel, D.; Maedche, A. (2002): A conceptual architecture for semantic web enabled web
services. In: SIGMOD Rec. 31 (4), S. 24–29.
Butler, T. (2011): Compliance with institutional imperatives on environmental sustainability: Building
theory on the role of Green IS. In: The Journal of Strategic Information Systems In Press, Corrected Proof, S. 1–21.
Buxmann, P.; Diaz, L. M.; Wüstner, E. (2002): XML-Based Supply Chain Management ‐ as SIMPLEX
as it Is. In: Sprague, R. H. (Hg.): Proceedings of the 35th Annual Hawaii International Conference
on System Sciences (HICSS'02), Bd. 7. Computer Society. Washington, DC, USA: IEEE Computer
Society, S. 2179–2188.
Buxmann, P.; Lehmann, S.; Hess, T. (2008): Software as a Service. In: Wirtschaftsinformatik 6, S.
500–503.
Campelo F., E. G.; Stucky, W. (2004): A Step Towards An Integrated Product Information Management. In: Nitya Karmakar und Pedro Isaías (Hg.): IADIS International Conference e-Commerce
2004, Proceedings, Single, S. 377–382.
Capaldo, G.; Rippa, P. (2008): A Methodological Proposal to Assess the Feasibility of ERP Systems
Implementation Strategies. In: Hawaii International Conference on System Sciences, S. 1–10.
Carey, M. J. (2008): SOA What? In: Computer 41 (3), S. 92–94.
Case, G.; DuMoulin, T.; Spalding, G.; Dissanayake, A. C. (2007): Service management strategies that
work. Guidance for executives. 1. Aufl. Zaltbommel: Van Haren Publishing.
Castaings, W.; Tarantola, S.; Latvala, A. (2007): The 2006 European e-Business Readiness Index.
Joint Research Centre – Institute for the Protection and Security of the Citizen. Luxembourg (Scientific and Technical Research series, EUR 22803 EN). Online verfügbar unter
http://publications.jrc.ec.europa.eu/repository/handle/111111111/13039, zuletzt geprüft am
08.02.2013.
Chan, C.; Swatman, P. M. (2002): Management and Business Issues for B2B eCommerce Implementation. In: Sprague, R. H. (Hg.): Proceedings of the 35th Annual Hawaii International Conference on
System Sciences (HICSS'02), Bd. 8. Computer Society. Washington, DC, USA: IEEE Computer
Society, S. 229.
Chan, P. Y.; Shi, X.; Wang, Y. (2007): A Theoretical and Strategic Framework for Information Systems. In: PACIS 2007 Proceedings.
Cheng, J.-H.; Yeh, C.-H.; Tu, C.-W. (2008): Trust and knowledge sharing in green supply chains. In:
Supply Chain Management: An International Journal 13 (4), S. 283–295.
Chen, M.-C.; Yang, T.; Li, H.-C. (2007): Evaluating the supply chain performance of IT-based interenterprise collaboration. In: Information & Management 44 (6), S. 524‐534.
Chen, W.; Huang, L.; Zhang, Q. (2005): The Adoption of Inter-Organizational Systems in Chinese
Local Retail Enterprises. In: PACIS, S. 1389–1395.
Chen, X. (2010): Google Scholar's Dramatic Coverage Improvement Five Years after Debut. In:
Serials Review 36 (4), S. 221–226.
243
Chong, A. Y.-L.; Ooi, K.-B. (2008): Adoption of interorganizational system standards in supply chains:
An empirical analysis of RosettaNet standards. In: Industrial Management & Data Systems 108 (4),
S. 529–547.
Chou, D. C.; Chou, A. Y. (2008): Software as a Service (SaaS) as an outsourcing model: An economic
analysis. In: SWDSI 2008 Proceedings, S. 386‐391.
Chou, D. C.; Tan, X.; Yen, D. C. (2004): Web technology and supply chain management. In: Information Management & Computer Security 12 (4), S. 338–349.
Chroust, G. (1992): Modelle der Software-Entwicklung. München, Wien: Oldenbourg.
Chui, M.; Miller, A.; Roberts, R. P. (2009): Six ways to make Web 2.0 work. In: McKinsey Quarterly (2),
S. 64–73.
Clement, T. (2008): The Social Collaboration Layer. An Enterprise Architectural View. Aegeon Corporation (Aegeon Discussion Paper).
Contreras, M.; Sheremetov, L. (2008): Industrial application integration using the unification approach
to agent-enabled semantic SOA. In: Robotics and Computer-Integrated Manufacturing 24 (5), S.
680–695.
Cooper, R. B.; Zmud, R. W. (1990): Information technology implementation research: A technological
diffusion approach. In: Management Science 36 (2), S. 123–139.
Crum, M. R.; Premkumar, G.; Ramamurthy, K. (1996): An assessment of motor carrier adoption, use,
and satisfaction with EDI. In: Transportation Journal 35 (4), S. 44–57.
Cyr, D.; Head, M.; Larios, H.; Bing Pan (2009): Exploring Human Images in Website Design: A MultiMethod-Approach. In: MIS Quarterly 33 (3), S. 539-A9.
Dan, A.; Dias, D. M.; Kearney, R.; Lau, T. C.; Nguyen, T. N.; Parr, F. N. et al. (2001): Business-tobusiness integration with tpaML and a business-to-business protocol framework. In: Technology 40
(1), S. 68–90.
Dao, V.; Langella, I.; Carbo, J. (2011): From green to sustainability: Information Technology and an
integrated sustainability framework. In: The Journal of Strategic Information Systems In Press, Corrected Proof, S. 1–17.
Darnall, N.; Jolley, G. J.; Handfield, R. (2008): Environmental Management Systems and Green
Supply Chain Management: Complements for Sustainability? In: Business Strategy and the Environment 17 (1), S. 30–45.
Davis, F. D. (1989): Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology. In: MIS Quarterly 13 (3), S. 319–340.
Dechow, N.; Mouritsen, J. (2005): Enterprise resource planning systems, management control and the
quest for integration. In: Accounting, Organizations and Society 30 (7-8), S. 691‐733.
Denzin, N. K. (1970): The research act in sociology. A theoretical introduction to sociological methods.
London: Butterworths.
Dibbern, J.; Goles, T.; Hirschheim, R.; Jayatilaka, B. (2004): Information systems outsourcing: a
survey and analysis of the literature. In: SIGMIS Database 35 (4), S. 6–102.
Dillon, T.; Wu, C.; Chang, E. (2010): Cloud Computing: Issues and Challenges. In: Advanced Information Networking and Applications (AINA), 2010 24th IEEE International Conference on. Advanced Information Networking and Applications (AINA): IEEE Computer Society, S. 27–33.
DIN SPEC 1041:2010-05, 2010: Outsourcing technologieorientierter wissensintensiver Dienstleistungen.
Djamasbi, S.; Siegel, M.; Tullis, T.; Dai, R. (2010): Efficiency, Trust, and Visual Appeal: Usability
Testing through Eye Tracking. In: Proceedings of the 43rd Hawaii International Conference on System Sciences (HICSS). IEEE Computer Society. Los Alamitos, S. 438–447.
Dorn, J.; Grun, C.; Werthner, H.; Zapletal, M. (2007): A Survey of B2B Methodologies and Technologies: From Business Models towards Deployment Artifacts. In: Hawaii International Conference on
System Sciences 0, S. 1–10.
Duchowski, A. (2007): Eye Tracking Methodology. Theory and Practice. Second. London: SpringerVerlag London Limited.
244
Dufft, N.; Tietz, S. (2007): Web 2.0 in Unternehmen: Potenziale von Wikis, Weblogs und Social
Software. Berlecon Research GmbH. Berlin.
Eckartz, S.; Daneva, M.; Wieringa, R.; van Hillegersberg, J. (2009): Cross-organizational ERP management: how to create a successful business case? In: SAC ‘09: Proceedings of the 2009 ACM
symposium on Applied Computing. New York, NY, USA: ACM, S. 1599‐1604.
Eckert, S.; Suchan, C.; Ferstl, O. K.; Schissler, M. (2005): Integration von Anwendungssystemen für
die Materialwirtschaft - Anwendung einer Entwicklungsmethodik im Bereich des Kraftwerkbaus. In:
Ferstl, O. K., Sinz, E. J., Eckert, S. und Isselhorst, T. (Hg.): Wirtschaftsinformatik 2005: eEconomy,
eGovernment, eSociety. 7. Internationale Tagung Wirtschaftsinformatik (WI 2005): Bamberg (23.25.02.2005). Heidelberg: Physica-Verlag Heidelberg, S. 1463–1482.
ECOLEAD (2007): D52.3 – A reference model for Collaborative Networks. Online verfügbar unter
http://www.ve-forum.org/projects/284/Deliverables/D52.3_final.pdf.
Eicker, S. (2012a): Software-Engineering. In: Kurbel, K., Becker, J., Gronau, N., Sinz, E. und Suhl, L.
Eicker, S. (2012b): Systementwicklung. In: Kurbel, K., Becker, J., Gronau, N., Sinz, E. und Suhl, L.
Elgarah, W.; Falaleeva, N.; Saunders, C. C.; Ilie, V.; Shim, J. T.; Courtney, J. F. (2005): Data exchange in interorganizational relationships: review through multiple conceptual lenses. In: SIGMIS
Database 36 (1), S. 8‐29.
Elkington, J. (2004): Enter the Triple Bottom Line. In: Henriques, A. und Richardson, J. (Hg.): The
triple bottom line, does it all add up? London: Earthscan, S. 1–16.
Elliot, S. (2007): Environmentally Sustainable ICT: A Critical Topic for IS Research? In: PACIS 2007
Proceedings, S. 100–112.
Elliot, S.; Binney, D. (2008): Environmentally Sustainable ICT: Developing Corporate Capabilities and
an Industry-relevant IS Research Agenda. In: PACIS 2008 Proceedings.
Erek, K.; Schmidt, N.-H.; Zarnekow, R.; Kolbe, L. M. (2010): Green IT im Rahmen eines nachhaltigen
Informationsmanagements. In: HMD - Praxis der Wirtschaftsinformatik (274), S. 18–27.
Eschenbächer, J. (2010): Supporting the selection of ICT systems within enterprise relationships by
analyzing collaboration intensities. In: Information and Communication Technologies for the Advanced Enterprise: an international journal 1 (1), S. 31–62.
Europäische Kommission (Hg.) (2003): Empfehlung der Kommission vom 6. Mai 2003 betreffend die
Definition der Kleinstunternehmen sowie der kleinen und mittleren Unternehmen. Online verfügbar
unter http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2003:124:0036:0041:de:PDF.
European Commission (Hg.) (2007): The European e-Business Report 2006/07. Office for Official
Publications of the European Communities. Online verfügbar unter http://www.ebusinesswatch.org/key_reports/documents/EBR06.pdf, zuletzt geprüft am 27.08.2009.
European Commission (Hg.) (2010): Synthesis Report 2009/10: "ICT and e-Business for an Innovative
and Sustainable Economy". Online verfügbar unter http://www.ebusinesswatch.org/key_reports/documents/EBR09-10.pdf, zuletzt geprüft am 06.08.2010.
Fathian, M.; Akhavan, P.; Hoorali, M. (2008): E-readiness assessment of non-profit ICT SMEs in a
developing country: The case of Iran. In: Technovation 28 (9), S. 578–590.
Fensel, D.; Bussler, C. (2002): The Web Service Modeling Framework WSMF. In: Electronic Commerce Research and Applications 1 (2), S. 113–137.
Ferneley, E.; Bell, F. (2006): Using bricolage to integrate business and information technology innovation in SMEs. In: Technovation 26 (2), S. 232–241.
Ferron, M.; Massa, P.; Odella, F. (2011): Analyzing collaborative networks emerging in Enterprise 2.0:
the Taolin Platform. In: Procedia - Social and Behavioral Sciences 10 (0), S. 68–78.
245
Filß, C.; Höhn, R.; Höppner, S.; Schumacher, M.; Wetzel, H. (2005): Rahmen zur Auswahl von
Vorgehensmodellen. Arbeitsbericht der GI Fachgruppe WI-VM, Arbeitskreis "Vorgehensmodelltypen".
Fischer, C.; Winter, R.; Wortmann, F. (2010): Gestaltungstheorie. In: Wirtschaftsinformatik 52 (6), S.
383–386.
Fleisch, E. (2001): Das Netzwerkunternehmen. Strategien und Prozesse zur Steigerung der Wettbewerbsfähigkeit in der "Networked economy". Berlin: Springer.
Franken, A.; Edwards, C.; Lambert, R. (2009): Executing Strategic Change: Understanding the critical
management elements that lead to success. In: California Management Review 51 (3), S. 49–73.
Furdík, K.; Mach, M.; Sabol, T. (2009): Towards Semantic Modelling of Business Processes for
Networked Enterprises. In: Di Noia, T. und Buccafurri, F. (Hg.): E-Commerce and Web Technologies, Bd. 5692: Springer Berlin / Heidelberg (Lecture Notes in Computer Science), S. 96–107.
Gadenne, V. (2001): Wozu sind Hypothesen gut? Zum Prinzip der Offenheit in der qualitativen Sozialforschung. In: Kontrapunkt: Jahrbuch für kritische Sozialwissenschaft und Philosophie 1, S. 11–26.
Gartner (2007): Gartner Estimates ICT Industry Accounts for 2 Percent of Global CO2 Emissions.
Unter Mitarbeit von Christy Pettey. Gartner Inc. Online verfügbar unter
http://www.gartner.com/it/page.jsp?id=503867, zuletzt geprüft am 26.08.2010.
Gassmann, O.; Enkel, E. (2006): Open Innovation: Externe Hebeleffekte in der Innovation erzielen. In:
Zeitschrift Führung + Organisation (3), S. 132–138.
Gautier, P. (2010): Inter-Organizational Relationships and Supply Chain Performance: Case Study of
the Subsidiary Company of a Car Parts Manufacturer. In: Proceedings of the International MultiConference of Engineers and Computer Scientists, Bd. 3. IMECS. Hong Kong, S. 1685–1690.
Glos, M. (2007): eBusiness-Standards im Mittelstand 2007. In: www.prozeus.de.
Grefen, P.; Ludwig, H.; Angelov, S. (2003): A Three-Level Framework for Process and Data Management of complex E-Services. In: International Journal of Cooperative Information Systems 12 (4),
S. 487–531.
Griese, B. (2005): Triangulation: Ein Forschungsmodell in der empirischen Sozialforschung . Online
verfügbar unter http://www.unimainz.de/FB/Paedagogik/Erwachsenenbildung/triangulationonline.pdf, zuletzt geprüft am
01.09.2012.
Grossman, M. (2004): The Role of Trust and Collaboration in the Internet-enabled Supply Chain. In:
Journal of American Academy of Business, Cambridge 5 (1/2), S. 391–396.
Gulledge, T. (2002): B2B eMarketplaces and small- and medium-sized enterprises. In: Computers in
Industry 49 (1), S. 47‐58.
Gulledge, T.; Simon, G. (2005): The evolution of SAP implementation environments: A case study
from a complex public sector project. In: Industrial Management & Data Systems 105 (6), S. 714–
736.
Gummesson, E. (2000): Qualitative methods in management research. 2nd. Thousand Oaks ;,
London: Sage.
Haas, B.; Jamjoum, A. K. (2008): In the Race to Be Green: Turn to IT. Information technology’s role in
promoting sustainability. In: A.T. Kearney, Inc., S. 1–12.
Hafner, M.; Winter, R. (2005): Vorgehensmodell für das Management der unternehmensweiten
Applikationsarchitektur. In: Ferstl, O. K., Sinz, E. J., Eckert, S. und Isselhorst, T. (Hg.): Wirtschaftsinformatik 2005: eEconomy, eGovernment, eSociety. 7. Internationale Tagung Wirtschaftsinformatik (WI 2005): Bamberg (23.-25.02.2005). Heidelberg: Physica-Verlag Heidelberg, S.
627–646.
Hagenhoff, S. (2004): Kooperationsformen: Grundtypen und spezielle Ausprägungen. Hg. v. Schumann, M. Georg-August-Universität Göttingen (Arbeitsbericht, 4), zuletzt geprüft am 18.10.2012.
Hain, S.; Back, A. (2011): Towards a Maturity Model for E-Collaboration - A Design Science Research
Approach. In: 44th Hawaii International Conference on System Sciences (HICSS), Bd. 0, S. 1–10.
246
Hansen, H. R. (1998): Wirtschaftsinformatik I. 7., völlig neubearb. und stark erw. Aufl., Nachdr.
Stuttgart: Fischer.
Harland, C. M.; Caldwell, N. D.; Powell, P.; Zheng, J. (2007): Barriers to supply chain information
integration: SMEs adrift of eLands. In: Journal of Operations Management 25 (6), S. 1234–1254.
Hasselbring, W. (2000): Information system integration. In: Commun. ACM 43 (6), S. 32‐38.
Heinrich, L. J. (1999): Informationsmanagement. Planung, Überwachung und Steuerung der Informationsinfrastruktur. 6., überarb. und erg. Aufl. München: Oldenbourg Verlag, München; Oldenbourg
(Wirtschaftsinformatik).
Heinrich, L. J. (Hg.) (2012): Geschichte der Wirtschaftsinformatik. Entstehung und Entwicklung einer
Wissenschaftsdisziplin. 2. Aufl. Berlin, Heidelberg: Springer Berlin Heidelberg.
Heinrich, L. J.; Burgholzer, P. (1994): Systemplanung I. Der Prozess der Systemplanung, der Vorstudie und der Feinstudie. 6., vollst. überarb. und erg. München: Oldenbourg (Systemplanung / von
Lutz J. Heinrich u. Peter Burgholzer, 1).
Heinrich, L. J.; Heinzl, A.; Roithmayr, F. (2004): Wirtschaftsinformatik-Lexikon. 7., vollst. überarb. und
erw. Aufl. München: Oldenbourg.
Heng, S. (2009): Green IT. Die IT ist nicht grün und wird es niemals sein! In: IM Information Management & Consulting (2), S. 95–96.
Herden, S.; Gomez, J. M.; Rautenstrauch, C.; Zwanziger, A. (2006): Software-Architekturen für das EBusiness. Enterprise-Application-Integration mit verteilten Systemen. Berlin: Springer.
Herden, S.; Zwanziger, A. (2009): Der Integrationsbegriff in der Wirtschaftsinformatik: Literaturanalyse,
Begriffsexplikation und Modell der Integrationsgegenstände. Institut für Wirtschaftsinformatik der
Universität Bern (Arbeitsbericht, 223.02).
Herendy, C. (2009): How to Research People’s First Impressions of Websites? Eye-Tracking as a
Usability Inspection Method and Online Focus Group Research. In: Godart, C., Gronau, N., Sharma, S. und Canals, G. (Hg.): Software Services for e-Business and e-Society, Bd. 305: Springer
Boston (IFIP Advances in Information and Communication Technology), S. 287–300. Online verfügbar unter http://dx.doi.org/10.1007/978-3-642-04280-5_23.
Herring, C.; Milosevic, Z. (2001): Implementing B2B Contracts using BizTalk. In: Hawaii International
Conference on System Sciences 9, S. 1–10.
Herzog, P. (2006): B2B-Integration: Motivation, Herausforderungen und Nutzen. In: Wölfle, R. und
Schubert, P. (Hg.): Prozessexzellenz mit Business Software. Praxislösungen im Detail : Fallstudien
- Konzepte - Modellierung. München [u.a.]: Hanser, S. 31–38.
Hess, T. (1998): Unternehmensnetzwerke: Abgrenzung, Ausprägung und Entstehung. Göttingen:
University Göttingen (4).
Hevner, A. R.; March, S. T.; Park, J.; Ram, S. (2004): Design Science in Information Systems Research. In: MIS Quarterly 28 (1), S. 75‐106.
He, W.; Ming, X. G.; Ni, Q. F.; Lu, W. F.; Lee, B. H. (2006): A unified product structure management
for enterprise business process integration throughout the product lifecycle. In: International Journal of Production Research 44 (9), S. 1757‐1776.
Hill, S. (2006): Enterprise integration as business strategy. In: Manufacturing Business Technology, S.
54–56.
Hinderer, H.; Otto, B.; Folmer, E. (2003): Automated Business Process Integration with OpenXchange.
In: IADIS International Conference WWW/Internet 2002 1, S. 113–120.
Hollingsed, T.; Novick, D. G. (2007): Usability inspection methods after 15 years of research and
practice. In: Proceedings of the 25th annual ACM international conference on Design of communication. New York, NY, USA: ACM (SIGDOC ‘07), S. 249–255.
Holtzblatt, L. J.; Damianos, L. E.; Weiss, D. (2010): Factors impeding Wiki use in the enterprise: a
case study. In: CHI EA ‘10: Proceedings of the 28th of the international conference extended abstracts on Human factors in computing systems. New York, NY, USA: ACM, S. 4661‐4676.
Howard, G. R.; Lubbe, S. (2012): Synthesis of green IS frameworks for achieving strong environmental sustainability in organisations. In: Proceedings of the South African Institute for Computer Scien-
247
tists and Information Technologists Conference. New York, NY, USA: ACM (SAICSIT ’12), S. 306–
315.
Hoyer, V.; Stanoevska-Slabeva, K. (2008): Enterprise Mashups - neue Herausforderung für das
Projektmanagement. In: HMD 260, S. 60–68.
Huang, Y.; Chung, J.-Y. (2003): A Web services-based framework for business integration solutions.
In: Electronic Commerce Research and Applications 2 (1), S. 15–26.
Hu, D.; Zhao, X.; Zhao, J. L. (2010): Strategic Choices of Inter-Organizational Information Systems: A
Customer-Supplier Network Perspective. In: 43rd Hawaii International Conference on System Sciences (HICSS), S. 1–8.
Hu, J.; Grefen, P. (2002): Component Based System Framework for Dynamic B2B Interaction. In:
Computer Software and Applications Conference, Annual International 0, S. 557–562.
Hwang, D.; Kenyon, M. (2004): FTP-Based EDI vs. Web Services: A Case Study in the Retailer
Industry. In: SCC ‘04: Proceedings of the 2004 IEEE International Conference on Services Computing. Washington, DC, USA: IEEE Computer Society, S. 553‐556.
Ibbs, C. W.; Wong, C. K.; Young Hoon Kwak (2001): Project Change Management System. In: Journal
of Management in Engineering 17 (3), S. 159–165.
Ijab, M. T.; Molla, A.; Kassahun, A. E.; Teoh, S. Y. (2010): Seeking the Green in Green IS: A Spirit,
Practice and Impact Perspective. In: PACIS 2010 Proceedings, S. 433–443.
Iskanius, P.; Kilpala, H. (2006): One step closer towards e-business - the implementation of a supporting ICT system. In: International Journal of Logistics: Research & Applications 9 (3), S. 283–293.
ISO 9241-110:2006, 2006: Ergonomics of human-system interaction -- Part 110: Dialogue principles.
Online verfügbar unter
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38009, zuletzt
ISO/IEC 7498-1:1994, 1994: Information technology -- Open Systems Interconnection -- Basic Reference Model: The Basic Model. Online verfügbar unter
http://www.iso.org/iso/catalogue_detail.htm?csnumber=20269, zuletzt geprüft am 22.02.2013.
ISO/IEC 10021-1:2003, 2003: Information technology -- Message Handling Systems (MHS) -- Part 1:
System and service overview. Online verfügbar unter
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=31632, zuletzt
ISO/IEC 15504:2004, 2004: Information technology -- Process assessment. Online verfügbar unter
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=38932, zuletzt
Jacob, R. J. K.; Karn, K. S. (2003): Eye Tracking in Human-Computer Interaction and Usability
Research: Ready to Deliver the Promises. In: Hyönä, J., Radach, R. und Deubel, H. (Hg.): The
Mind's Eye (First Edition). Amsterdam: North-Holland, S. 573–605. Online verfügbar unter
http://www.sciencedirect.com/science/article/B844J-4MSYX19S/2/95e7dfe67d15ea6a1cda73dacdadb84e.
Jenkin, T. A.; Webster, J.; McShane, L. (2011): An agenda for Green information technology and
systems research. In: Information and Organization 21 (1), S. 17–40.
Jeong, B.; Lee, D.; Cho, H.; Lee, J. (2008): A novel method for measuring semantic similarity for XML
schema matching. In: Expert Systems with Applications 34 (3), S. 1651–1658.
Joung, Y.-J.; Chuang, F.-Y. (2009): OntoZilla: An ontology-based, semi-structured, and evolutionary
peer-to-peer network for information systems and services. In: Future Generation Computer Systems 25 (1), S. 53‐63.
Jung, J.-Y.; Kim, H.; Kang, S.-H. (2006): Standards-based approaches to B2B workflow integration. In:
Computers & Industrial Engineering 51 (2), S. 321‐334.
Kajan, E. (2004): The maturity of open systems for B2B. In: ACM SIGEcom Exchanges 5 (2), S. 34–
44.
Karle, T.; Oberweis, A. (2006): Unterstützung von Kollaboration im Rahmen der Softwareentwicklung
auf Basis Service-orientierter Architekturen. In: Weske, M. und Nüttgens, M. (Hg.): Methoden, Kon-
248
zepte und Technologien für die Entwicklung von dienstbasierten Informationssystemen, Beiträge
des Workshops der GI-Fachgruppe Entwicklungsmethoden für Informationssysteme und deren
Anwendung (EMISA). Hamburg, 17.-18.10.2006: GI (LNI, 95), S. 77–90.
Keen, P. G. W. (1981): Information systems and organizational change. In: Communications of the
ACM 24 (1), S. 24–33.
Keifer, S. (2011): E-invoicing: The catalyst for financial supply chain efficiencies. In: Journal of Payments Strategy & Systems 5 (1), S. 38–51.
Kelle, P.; Akbulut, A. (2005): The role of ERP tools in supply chain information sharing, cooperation,
and cost optimization. In: International Journal of Production Economics 93-94 (1), S. 41–52.
Kim, H.-W.; Pan, S. L. (2006): Towards a process model of information systems implementation: the
case of customer relationship management (CRM). In: SIGMIS Database 37 (1), S. 59–76.
Kim, S. W.; Park, S. (2008): Development of a three-echelon SC model to optimize coordination costs.
In: European Journal of Operational Research 184 (3), S. 1044‐1061.
Koch, M.; Richter, A. (2007): Enterprise 2.0. Planung, Einführung und erfolgreicher Einsatz von Social
Software in Unternehmen. München, Wien: Oldenbourg.
Koch, M.; Richter, A. (2009): Enterprise 2.0. Planung, Einführung und erfolgreicher Einsatz von Social
Software in Unternehmen. 2., aktualisierte und erw. Aufl. München: Oldenbourg.
Koch, M.; Richter, A.; Schlosser, A. (2007): Produkte zum IT-gestützten Social Networking in Unternehmen. In: Wirtschaftsinformatik 49 (6), S. 448–455.
Koch, O. (2008): Strategieorientierte Einführung komplexer Softwaresysteme. Vorgehensmodell zur
Sicherung von Wettbewerbsvorteilen und zum TCO-optimierenden Projektmanagement. Kassel,
Hess: WITEC - Verlag für Wirtschaft, Informatik und Technik OHG.
Kommission der Europäischen Gemeinschaften (Hg.) (2008): Verbesserung der Energieeffizienz
durch Informations- und Kommunikationstechnologien (241). Online verfügbar unter http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2008:0241:FIN:DE:PDF, zuletzt geprüft am
26.08.2010.
Krallmann, H. (2012): Wirtschaftsinformatik – Zwischen Praxis und Forschung. In: Heinrich, L. J. (Hg.):
Geschichte der Wirtschaftsinformatik. Entstehung und Entwicklung einer Wissenschaftsdisziplin. 2.
Aufl. Berlin, Heidelberg: Springer Berlin Heidelberg, S. 106–114.
Kranz, J.; Janello, C.; Picot, A. (2009): Die Rolle von Web 2.0-Prinizipien im Innovationsprozess. In:
IM Information Management & Consulting (2), S. 39–47.
Kühn, H.; Karagiannis, D. (2005): Strategie-, Prozess- und IT-Management: Ein Pattern-orientierter
Integrationsansatz. In: Ferstl, O. K., Sinz, E. J., Eckert, S. und Isselhorst, T. (Hg.): Wirtschaftsinformatik 2005: eEconomy, eGovernment, eSociety. 7. Internationale Tagung Wirtschaftsinformatik
(WI 2005): Bamberg (23.-25.02.2005). Heidelberg: Physica-Verlag Heidelberg, S. 1483–1502.
Kuhrmann, M. (2012): Agile Vorgehensmodelle. In: Kurbel, K., Becker, J., Gronau, N., Sinz, E. und
Suhl, L. (Hg.): Enzyklopädie der Wirtschaftsinformatik – Online-Lexikon. Sechste Auflage. München: Oldenbourg. Online verfügbar unter http://www.enzyklopaedie-der-wirtschaftsinformatik.de/,
zuletzt geprüft am 30.11.2012.
Kumaran, S.; Bishop, P.; Chao, T.; Dhoolia, P.; Jain, P.; Jaluka, R. et al. (2007): Using a model-driven
transformational approach and service-oriented architecture for service delivery management. In:
IBM Systems Journal 46 (3), S. 513–529.
Kumar, K.; van Hillegersberg, J. (2000): ERP - Experiences and Evolution. In: Communications of the
ACM 43 (4), S. 22‐26.
Kunti, K.; Chawla, M.; Sitaram, V. (2007): Leveraging shared data services in data integration. A
seamless approach for implementing standards-based data integration projects. In: Mathew, G. E.
(Hg.): Service Oriented Architecture - Managing the Hype. 1. Aufl. 5 Bände (5), S. 3–8.
Kupsch, F.; Werth, D. (2003): A Peer-to-Peer Approach for Business Integration. In: Proceedings of
the 5th International Conference MITIP 2003 "The Modern Information Technology in the Innovation Processes of the Industrial Enterprises", Saarbruecken, S. 68–73.
Lacity, M. C.; Khan, S. A.; Willcocks, L. P. (2009): A review of the IT outsourcing literature: Insights for
practice. In: The Journal of Strategic Information Systems 18 (3), S. 130–146.
249
Lambert, D. M.; Emmelhainz, M. A.; Gardner, J. T. (1996): Developing and Implementing Supply
Chain Partnerships. In: The International Journal of Logistics Management 7 (2), S. 1–18.
Lamnek, S. (2005): Qualitative Sozialforschung. Lehrbuch. 4., vollst. überarb. Weinheim ;, Basel:
Beltz, PVU.
Lanninger, V. (2009): Prozessmodell zur Auswahl betrieblicher Standardanwendungssoftware für
KMU. 1. Aufl. Lohmar ;, Köln: Eul.
Lebender, M.; Ondrusch, N.; Otto, B.; Renner, T. (2003): Business Integration Software: Werkzeuge,
Anbieter, Lösungen: media vision expert.
Lee, K. J.; Casalegno, F. (2010): An Explorative Study for Business Models for Sustainability. In:
PACIS 2010 Proceedings, S. 423–432.
Legner, C. (2009): Understanding the manifold forms of B2B integration. A transaction cost perspective. In: Newell, S., Whitley, E. A., Pouloudi, N., Wareham, J. und Mathiassen, L. (Hg.): Proceedings of the 17th European Conference on Information Systems. Verona, Italy, S. 2761–2772.
Lehner, F.; Amende, N.; Wildner, S.; Haas, N. (2009a): KnowMetrix - Erfahrungen mit der Erfolgsbewertung im Wissensmanagement in einem mittelständischen Unternehmen. In: Hinkelmann, K. und
Wache, H. (Hg.): WM2009: 5th Conference on Professional Knowledge Management. March 25 –
27, 2009, Solothurn, Switzerland. Gesellschaft für Informatik, S. 470–479.
Lehner, F.; Hildebrandt, K.; Maier, R. (1995): Wirtschaftsinformatik. Theoretische Grundlagen. München ;, Wien: Hanser.
Lehner, F.; Scholz, M.; Wildner, S. (2009b): Wissensmanagement. Grundlagen, Methoden und
technische Unterstützung. 3., aktualisierte und erw. Aufl. München: Hanser (Hanser Kompetenz
gewinnt).
Leimstoll, U.; Schubert, P. (2005): Integration von Business Software - Eine Studie zum aktuellen
Stand in Schweizer KMU. In: Ferstl, O. K., Sinz, E. J., Eckert, S. und Isselhorst, T. (Hg.): Wirtschaftsinformatik 2005: eEconomy, eGovernment, eSociety. 7. Internationale Tagung Wirtschaftsinformatik (WI 2005): Bamberg (23.-25.02.2005). Heidelberg: Physica-Verlag Heidelberg, S.
983–1002.
Levy, M.; Powell, P. (2000): Information systems strategy for small and medium sized enterprises: an
organisational perspective. In: The Journal of Strategic Information Systems 9 (1), S. 63–84.
Linthicum, D. S. (2000): B2B Application Integration. E-Business-Enable Your Enterprise. Reading,
Mass: Addison-Wesley.
Liu, Z.; Wang, G.; Liu, P. (2011): Information Sharing among Members of the Supply Chain from the
Perspective of Game. In: AISS: Advances in Information Sciences and Service Sciences 3 (2), S.
152–159.
Loh, L.; Venkatraman, N. (1992): Diffusion of Information Technology Outsourcing: Influence Sources
and the Kodak Effect. In: Information Systems Research 3 (4), S. 334–358.
Loos, P.; Nebel, W.; Marx Gómez, J.; Hasan, H.; Watson, R.; Vom Brocke, J. et al. (2011): Green IT:
Ein Thema für die Wirtschaftsinformatik? In: Wirtschaftsinformatik 53 (4), S. 239–247.
Lorenz, W.-D. (2008): Das Öko-Gewissen der IT-Branche schlägt. In: IM Information Management &
Consulting (1), S. 83–85.
Luvsanbyamba, M.; Chung, K. in (2009): An empirical study of success factors on business-tobusiness e-marketplaces from buyers’ and sellers’ perspectives. In: Proceedings of the 2nd International Conference on Interaction Sciences: Information Technology, Culture and Human. Seoul,
Korea. New York, NY, USA: ACM (ICIS 2009), S. 486‐491.
Lyytinen, K.; Damsgaard, J. (2001): What’s Wrong with the Diffusion of Innovation Theory. The case of
a complex and networked technology. In: Proceedings of the IFIP TC8 WG8.1 Fourth Working
Conference on Diffusing Software Products and Process Innovations. Deventer, The Netherlands:
Kluwer, B.V, S. 173–190.
Maamar, Z.; Thiran, P.; Narendra, N. C.; Subramanian, S. (2008): A Framework for Modeling B2B
Applications. In: Proceedings of the 22nd International Conference on Advanced Information Networking and Applications: IEEE, S. 12–19.
250
Ma, D. (2007): The Business Model of "Software-As-A-Service". In: IEEE International Conference on
Services Computing, S. 701–702.
Madlberger, M. (2008): Einsatz von RFID im Supply Chain Management: Eine empirische Analyse der
Einflussfaktoren. In: Martin Bichler, Thomas Hess, Helmut Krcmar, Ulrike Lechner, Florian Matthes,
Arnold Picot et al. (Hg.): Multikonferenz Wirtschaftsinformatik, MKWI 2008, München, 26.2.2008 28.2.2008, Proceedings: GITO-Verlag, Berlin, S. 849–860.
Malhotra, M. K.; Grover, V. (1998): An assessment of survey research in POM: from constructs to
theory. In: Journal of Operations Management 16 (4), S. 407–425.
Malone, T. W.; Yates, J.; Benjamin, R. I. (1987): Electronic markets and electronic hierarchies. In:
Communications of the ACM 30 (6), S. 484–497.
Manz, U.; Dortschy, W.; Köber, M.; Mrotzeck, A.; Tölke, I. (2004): Produktivitätsfortschritt durch den
Einsatz von E-Commerce-Standards. Modellierung einer "Standardisierungs-Road-Map": Fachhochschule Darmstadt, Fachbereich Wirtschaft.
Marcais, T. (2008): Green Computing – It IS Easy Being Green. In: Proceedings of the ASCUE
Summer Conference, S. 122–127.
Marquardt, K. (2003): Vorgehensmodell zur Durchführung von IT-Projekten unter expliziter Einbeziehung der Kundensicht. In: Wirtschaftsinformatik 2003: Medien - Märkte - Mobilität 2 Bde: PhysicaVerlag, S. 921‐946.
McAfee, A. P. (2006a): Enterprise 2.0, version 2.0. Blog Post vom 27.05.2006. Online verfügbar unter
http://andrewmcafee.org/2006/05/enterprise_20_version_20/, zuletzt geprüft am 20.08.2009.
McAfee, A. P. (2006b): Enterprise 2.0: The Dawn Of Emergent Collaboration. In: MIT Sloan Management Review 47 (3), S. 21–28.
McAfee, A. P. (2009): Enterprise 2.0. New collaborative tools for your organization's toughest challenges. Boston, Mass.: Harvard Business Press.
McMaster, T.; DeGross, J. I.; Ferneley, E.; Wastell, D. (2007): Organizational Dynamics of Technology-Based Innovation: Diversifying the Research Agenda. IFIP TC 8 WG 8.6 International Working
Conference, June 14-16, Manchester, UK. Online-Ausg. Boston, MA: International Federation for
Information Processing.
Medjahed, B.; Benatallah, B.; Bouguettaya, A.; Ngu, A. H. H.; Elmagarmid, A. K. (2003): Business-tobusiness interactions: issues and enabling technologies. In: The VLDB Journal 12 (1), S. 59‐85.
Meier, J. J.; Conkling, T. W. (2008): Google Scholar’s Coverage of the Engineering Literature: An
Empirical Study. In: The Journal of Academic Librarianship 34 (3), S. 196–201.
Mentzer, J. T. (2008): Rigor versus relevance: why would we choose only one? In: Journal of Supply
Chain Management 44 (2), S. 72.
Mertens, P. (1966): Die zwischenbetriebliche Kooperation und Integration bei der automatisierten
Datenverarbeitung. Meisenheim am Glan: Anton Hain KG.
Mertens, P.; Bodendorf, F.; König, W.; Picot, A.; Schumann, M. (2000): Grundzüge der Wirtschaftsinformatik. 6., überarb. Aufl. Berlin: Springer (Springer-Lehrbuch).
Mey, S. (2010): Manager wissen zu wenig über Öko-IT. Hg. v. WirtschaftsBlatt. Online verfügbar unter
http://www.wirtschaftsblatt.at/home/schwerpunkt/itnews/419544, zuletzt aktualisiert am 03.05.2010,
Mingay, S. (2007): Green IT: The New Industry Shock Wave. Hg. v. Gartner RAS Core Research Note
G00153703.
Moghaddam, F. F.; Cheriet, M.; Nguyen, K. K. (2011): Low Carbon Virtual Private Clouds. In: IEEE
International Conference on Cloud Computing (CLOUD), S. 259–266.
Molla, A. (2008): GITAM: A Model for the Acceptance of Green IT. In: 19th Australasian Conference
on Information Systems, S. 658–668.
Molla, A. (2009): Organizational Motivations for Green IT: Exploring Green IT Matrix and Motivation
Models. In: PACIS 2009 Proceedings, S. 1–13.
251
Molla, A.; Cooper, V.; Corbitt, B.; Deng, H.; Peszynski, K.; Pittayachawan, S.; Teoh, S. Y. (2008): EReadiness to G-Readiness: Developing a Green Information Technology Readiness Framework.
In: 19th Australasian Conference on Information Systems, S. 669–678.
Molla, A.; Cooper, V.; Pittayachawan, S. (2011): The Green IT Readiness (G-Readiness) of Organizations: An Exploratory Analysis of a Construct and Instrument. In: Communications of the ACM 29
(1), S. 67–96.
Molla, A.; Pittayachawan, S.; Corbitt, B.; Deng, H. (2009): An International Comparison of Green IT
Diffusion. In: International Journal of e-Business Management 3 (3), S. 3–23.
Moran-Ellis, J.; Alexander, V. D.; Cronin, A.; Dickinson, M.; Fielding, J.; Sleney, J.; Thomas, H. (2006):
Triangulation and integration: processes, claims and implications. In: Qualitative Research 6 (1), S.
45–59.
Morien, R.; Jitprapaikulsarn, S.; Scherrey, B. (2008): Agile development methods: A Development
paradigm for the Digital Ecosystem. In: Digital Ecosystems and Technologies (DEST 2008), 2nd
IEEE International Conference on, S. cviii–cx.
Murugesan, S. (2008): Harnessing Green IT: Principles and Practices. In: IT Professional 10 (1), S.
24–33.
Natour, A.; Kiridena, S.; Gibson, P. (2011): Supply chain integration and collaboration for performance
improvement: an agency theory approach. In: 9th ANZAM Operations, Supply Chain and Services
Management Symposium. Geelong: Deakin University, S. 503–519.
Naumann, J. D.; Jenkins, M. A. (1982): Protoyping: The New Paradigm for Systems Development. In:
MIS Quarterly 6 (3), S. 29–44.
Nedbal, D. (2011): Guiding B2B Integration of Business Processes and Services. A Process Model for
SMEs. In: Proceedings of 2nd International Conference on Emerging Intelligent Data and Web
Technologies (EIDWT-2011). IEEE Computer Society. Tirana, Albania: IEEE.
Nedbal, D. (2012): An Examination of the Economic Value and Contribution to Energy Efficiency of
SaaS Solutions: The Case of E-Invoicing. In: Services Economics (SE), 2012 IEEE First International Conference on. Honolulu, USA: IEEE.
Nedbal, D. (2013): A Process Model to guide the Integration of Business Processes and Services
within and across Organizations. In: International Journal of Services, Economics and Management
5 (1), S. 154–177.
Nedbal, D.; Auinger, A. (2010a): Effektives Supply Chain Information Management in Wertschöpfungsnetzwerken mittels Enterprise 2.0. In: Staberhofer, F. und Engelhardt-Nowitzki, C. (Hg.): Forschungsbeiträge zur Logistik: Shaker Verlag, S. 169–180.
Nedbal, D.; Auinger, A. (2010b): Framework zur Steigerung der Energieeffizienz durch unternehmensübergreifende B2B Integrationen. In: Energieeffiziente Mobilität: Shaker Verlag, S. 92–104.
Nedbal, D.; Auinger, A.; Hochmeier, A.; Holzinger, A. (2012a): A Systematic Success Factor Analysis
in the Context of Enterprise 2.0: Results of an Exploratory Analysis Comprising Digital Immigrants
and Digital Natives. In: Huemer, C. und Lops, P. (Hg.): E-Commerce and Web Technologies. 13th
International Conference, EC-Web 2012, Bd. 123: Springer Berlin Heidelberg (Lecture Notes in
Business Information Processing), S. 163–175.
Nedbal, D.; Auinger, A.; Wöß, W. (2012b): Business-to-Business-Integration in Wertschöpfungsnetzwerken. In: HMD - Praxis der Wirtschaftsinformatik (285), S. 63–72.
Nedbal, D.; Wetzlinger, W. (2012): Technical Complexity as Important Factor for Green IS Solutions:
Theoretical Background and Exploratory Study. In: Conf-IRM 2012 Proceedings. Conf-IRM. Vienna, Austria.
Nedbal, D.; Wetzlinger, W.; Auinger, A.; and Wagner, G. (2011): Sustainable IS Initialization Through
Outsourcing: A Theory-Based Approach. In: AMCIS 2011 Proceedings. Detroit, USA.
Nedbal, D.; Wetzlinger, W.; Kern, T. (2012c): Handlungsfelder und Lösungsansätze im Kontext von
"Green IS": Eine explorative Studie. In: Proceedings FFH 2012. Forschungsforum der österreichischen Fachhochschulen. Graz, Austria, S. 95–99.
Nehring, H. (2003): Enterprise Integration. In: future network Journal 1, S. 7–8.
252
Nielsen, J.; Molich, R. (1990): Heuristic evaluation of user interfaces. In: Proceedings of the SIGCHI
conference on Human factors in computing systems: Empowering people. New York, NY, USA:
ACM (CHI ‘90), S. 249–256.
Nolan, R. (1979): Managing The Crisis In Data Processing. In: Harvard Business Review 57 (2), S.
115–126.
Norta, A. (2007): A Conceptual Vision for Automated Business-to-Business Collaboration. In: Proceedings of the Finnish Science Day 2007, S. 1–6.
Norta, A.; Hendrix, M.; Grefen, P. (2006): A Pattern-Knowledge Base Supported Establishment of
Inter-Organizational Business Processes. In: Meersman, R. und Tari, Z. (Hg.): On the Move to
Meaningful Internet Systems 2006: CoopIS, DOA, and ODBASE, Bd. 3760. Agia Napa, Cyprus:
LNCS Springer (Lecture Notes in Computer Science), S. 834–843.
Nurmilaakso, J.-M. (2009): EDI-based and XML-based business-to-business integration: a statistical
analysis. In: Int. J. Bus. Inf. Syst 4, S. 639‐654.
Nurmilaakso, J.-M.; Kotinurmi, P.; Laesvuori, H. (2006): XML-based e-business frameworks and
standardization. In: Computer Standards & Interfaces 28 (5), S. 585‐599.
Oestereich, B. (2007): OEP - oose Engineering Process. Vorgehensleitfaden für agile Softwareprojekte. 1. Aufl. Heidelberg: dpunkt-Verl.
Omelayenko, B. (2001): Syntactic-Level Ontology Integration Rules for E-commerce. In: Proceedings
of The 14th International FLAIRS Conference, Key West FL: AAAI Press.
Omelayenko, B. (2002): RDFT: A Mapping Meta-Ontology for Business Integration. In: Proceedings of
the Workshop on Knowledge Transformation for the Semantic for the Semantic Web at the 15th
European Conference on Artificial Intelligence (KTSW-2002), S. 76‐83.
O'Reilly, T. (2007): What is Web 2.0: Design patterns and business models for the next generation of
software. In: Communications & strategies (1), S. 17–37.
Orlikowski, W. J. (1992): The duality of technology: Rethinking the concept of technology in organizations. In: Organization Science 3 (3), S. 398–427.
Orsato, R. J. (2006): Competitive Environmental Strategies: When Does It Pay to Be Green? In:
California Management Review 2 (48), S. 127–143.
Österle, H. (1995): Business Engineering 1. Prozeß- und Systementwicklung. 2., verb. Aufl. Berlin:
Springer.
Österle, H.; Becker, J.; Frank, U.; Hess, T.; Karagiannis, D.; Krcmar, H. et al. (2010): Memorandum
zur gestaltungsorientierten Wirtschaftsinformatik. In: Zeitschrift für betriebswirtschaftliche Forschung (11), S. 664–669.
Österle, H.; Brenner, W.; Hilbers, K. (1992): Unternehmensführung und Informationssystem. Der
Ansatz des St. Galler Informationssystem-Managements. Stuttgart: Teubner (Informatik und Unternehmensführung).
Österle, H.; Fleisch, E.; Alt, R. (2002): Business networking in der Praxis. Beispiele und Strategien zur
Vernetzung mit Kunden und Lieferanten. Berlin ;, Heidelberg ;, New York ;, Barcelona ;, Hongkong
;, London ;, Mailand ;, Paris ;, Tokio: Springer.
Österle, H.; Winter, R. (Hg.) (2000): Business Engineering. Auf dem Weg zum Unternehmen des
Informationszeitalters. Berlin: Springer.
Otto, B.; Beckmann, H.; Kelkar, O.; Müller, S. (2002): E-Business-Standards: Verbreitung und Akzeptanz. Online verfügbar unter http://www.media-vision.iao.fraunhofer.de/e-business_standards.html.
Overby, E. (2008): Process virtualization theory and the impact of information technology. In: Organization Science 19 (2), S. 277–291.
Panayides, P. M.; Venus Lun, Y. H. (2009): The impact of trust on innovativeness and supply chain
performance. In: International Journal of Production Economics 122 (1), S. 35–46.
Pang, V.; Bunker, D. (2007): Inter-Organisational Systems (IOS) for Supply Chain Management..
PACIS. 2007. In: PACIS 2007 Proceedings.
Papazoglou, M. P.; van Den Heuvel, W. J. (2006): Service-oriented design and development methodology. In: International Journal of Web Engineering and Technology 2 (4), S. 412–442.
253
Pathirage, M.; Perera, S.; Kumara, I.; Weerawarana, S. (2011): A Multi-tenant Architecture for Business Process Executions. In: IEEE International Conference on Web Services (ICWS), S. 121–
128.
Patterson, K. A.; Grimm, C. M.; Corsi, T. M. (2003): Adopting new technologies for supply chain
management. In: Transportation Research Part E: Logistics and Transportation Review 39 (2), S.
95–121.
Paulzen, O.; Haas, S. (2002): Integration von Knowledge Warehouse und Knowledge Networks.
Konzept und Methodik am Beispiel des Intelligent Supplier Management. In: Herget, J. (Hg.): Competitive & Business Intelligence - Neue Konzepte, Methoden & Instrumente. Konstanz/Berlin, S.
29–50.
Perin de Souza, A.; Rabelo, R. J. (2011): A Model for Dynamic Services Discovery over Largely
Distributed Providers Based on QoS and Business Processes Contexts. In: IEEE World Congress
on Services (SERVICES), S. 347–354.
Petrie, H.; Buykx, L. (2010): Collaborative Heuristic Evaluation: Improving the effectiveness of heuristic
evaluation. In: Proceedings of UPA 2010 Conference, S. 1–6.
Piccinelli, G.; Finkelstein, A.; Costa, T. (2003): Flexible B2B processes: the answer is in the nodes. In:
Information and Software Technology 45 (15), S. 1061‐1063.
Picot, A.; Baumann, O. (2009): Die Bedeutung der Organisationstheorie für die Entwicklung der
Wirtschaftsinformatik. In: Wirtschaftsinformatik 51 (1), S. 72–81.
Polaschek, M.; Zeppelzauer, W.; Kryvinska, N.; Strauss, C. (2012): Enterprise 2.0 Integrated Communication and Collaboration Platform. A Conceptual Viewpoint. In: First International Workshop on
inter-Clouds and Collective Intelligence (iCCI-2012).
Pomberger, G.; Blaschek, G. (1996): Software-Engineering. Prototyping und objektorientierte Software-Entwicklung. 2., überarb. München [u.a.]: Hanser.
Pomberger, G.; Pree, W. (2004): Software Engineering. Architektur-Design und Prozessorientierung.
3., vollst. überarb. München ;, Wien: Hanser.
Pomberger, G.; Weinreich, R. (1994): The Role of Prototyping in Software Development. In: Magnusson, B., Meyer, B., Nerson, J.-M. und Perrot, J.-F. (Hg.): TOOLS 1994: 13th International Conference on Technology of Object-Oriented Languages and Systems, Versailles, France, Europe:
Prentice Hall, S. 525.
Poon, P.-L.; Lau, A. H. L. (2006): The PRESENT B2C implementation framework. In: Communications
of the ACM 49, S. 96–103.
Porter, M. E. (2008): Wettbewerbsstrategie (Competitive strategy). Methoden zur Analyse von Branchen und Konkurrenten. 11., durchges. Frankfurt: Campus-Verlag, Frankfurt.
Power, D. (2005): Supply chain management integration and implementation: a literature review. In:
Supply Chain Management: An International Journal 10 (4), S. 252–263.
Prell, M. (2010): Die Vergaberechtsreform 2009/2010 - neue Perspektiven der öffentlichen Beschaffung bei Green IT. In: IM Information Management & Consulting (02), S. 90–93.
Premkumar, G. P. (2000): Interorganization Systems and Supply Chain Management: An Information
Processing Perspective. In: Information Systems Management 17 (3), S. 56–69.
Quantz, J.; Wichmann, T. (2003): Basisreport Integration mit Web Services - Konzept, Fallstudien und
Bewertung. Berlecon Research.
Radeke, F. (2010): How to Rigorously Develop Process Theory Using Case Research. In: Proceedings of the 18th European Conference on Information Systems (ECIS 2010), S. 1–12.
Ramdani, B.; Kawalek, P. (2007): SME Adoption of Enterprise Systems in the Northwest of England.
An Environmental, Technological, and Organizational Perspective. In: McMaster, T., Wastell, D.,
Ferneley, E. und DeGross, J. (Hg.): Organizational Dynamics of Technology-Based Innovation:
Diversifying the Research Agenda, Bd. 235: Springer Boston (IFIP International Federation for Information Processing), S. 409–430. Online verfügbar unter http://dx.doi.org/10.1007/978-0-38772804-9_27.
Rashid, A.; Behm, A.; Geisser, M.; Hildenbrand, T. (2006): Kollaborative Softwareentwicklung - Zum
Kollaborationsbegriff (Arbeitspapier aus dem Projekt CollaBaWü).
254
Reichwald, R.; Piller, F. (2006): Interaktive Wertschöpfung. Open Innovation, Individualisierung und
neue Formen der Arbeitsteilung. Wiesbaden: Gabler (Springer-11775 /Dig. Serial]).
Riedl, D.; Betz, F. (2012): Intranet 2.0 Based Knowledge Production. An Exploratory Case Study on
Barriers for Social Software. In: Mauri, J. L. und Lorenz, P. (Hg.): The Fourth International Conference on Information, Process, and Knowledge Management. eKNOW. Valencia, Spain, January 30
- February 4. IARIA, S. 1‐6.
Riedl, R.; Roithmayr, F. (2006): Fallstudien zum Management von IT-Projekten. Linz: Trauner Verlag.
Ritz, T.; Stender, M. (2003): B2B Mobile Business Processes: Scenarios and Technologies. In:
Database and Expert Systems Applications, International Workshop on, S. 885–889.
Robertson, R. (2005): A framework of critical drivers in successful business-to-business e-commerce.
In: SoutheastCon, 2005. Proceedings. IEEE, S. 378–383.
Roberts, S. (2004): OECD work on measuring the Information Society. In: 3rd meeting of the Asia
Pacific Technical Meeting on ICT Statistics, Wellington, New Zealand, S. 1–17.
Rogers, E. M. (1983): Diffusion of innovations. 3. ed. New York, NY u. a.: Free Press.
Rogers, E. M. (2003): Diffusion of innovations. 5. Aufl. New York: Free Press.
Rohrbeck, R.; Hölzle, K.; Gemünden, H. G. (2009): Opening up for competitive advantage – How
Deutsche Telekom creates an open innovation ecosystem. In: R&D Management 39 (4), S. 420–
430.
Roithmayr, F. (2012): Von der Hard Systems zur Soft Systems Methodology. In: Heinrich, L. J. (Hg.):
Geschichte der Wirtschaftsinformatik. Entstehung und Entwicklung einer Wissenschaftsdisziplin. 2.
Aufl. Berlin, Heidelberg: Springer Berlin Heidelberg, S. 146–151.
Rossi, G.; Schmid, H.; Lyardet, F. (2003): Customizing Business Processes in Web Applications. In:
Bauknecht, K., Tjoa, A. und Quirchmayr, G. (Hg.): E-Commerce and Web Technologies, Bd. 2738:
Springer Berlin / Heidelberg (Lecture Notes in Computer Science), S. 359–368.
Royce, W. W. (1987): Managing the development of large software systems: concepts and techniques. In: Proceedings of the 9th international conference on Software Engineering. Los Alamitos,
CA, USA: IEEE Computer Society Press (ICSE ‘87), S. 328‐338.
Ruile, H. (2006): Prozessoptimierung in der Auftragsabwicklung. In: Wölfle, R. und Schubert, P. (Hg.):
Prozessexzellenz mit Business Software. Praxislösungen im Detail : Fallstudien - Konzepte - Modellierung. München [u.a.]: Hanser, S. 131–138.
Sabherwal, R.; Robey, D. (1993): An Empirical Taxonomy of Implementation Processes Based on
Sequences of Events in Information System Development. In: Organization Science 4 (4), S. 548–
576.
Saccani, N.; Johansson, P.; Perona, M. (2007): Configuring the after-sales service supply chain: A
multiple case study. In: International Journal of Production Economics 110 (1-2), S. 52‐69.
Saha, P. (2004): Analyzing The Open Group Architecture Framework from the GERAM Perspective.
Hg. v. The Open Group Architecture Forum. Institute of Systems Science, National University of
Singapore. Online verfügbar unter
http://www.opengroup.org/architecture/wp/saha/TOGAF_GERAM_Mapping.pdf, zuletzt geprüft am
06.11.2012.
Samson, T. (2007): Green tech vs. sustainable tech. Hg. v. Infoworld. Online verfügbar unter
http://www.infoworld.com/d/green-it/green-tech-vs-sustainable-tech-691, zuletzt geprüft am
02.02.2011.
Sarkis, J.; Zhu, Q.; Lai, K.-h. (2011): An organizational theoretic review of green supply chain management literature. In: International Journal of Production Economics 130 (1), S. 1–15.
Schlieter, H.; Juhrisch, M.; Niggemann, S. (2010): The Challenge of Energy Management – StatusQuo and Perspectives for Reference Models. In: PACIS 2010 Proceedings.
Schmalz, J. S. (2007): Zwischen Kooperation und Kollaboration, zwischen Hierarchie und Heterarchie.
Organisationsprinzipien und -strukturen von Wikis. In: Sonderausgabe von kommunikation@gesellschaft 8.
255
Schmidt, N.-H.; Erek, K.; Kolbe, L. M.; Zarnekow, R. (2009): Towards a Procedural Model for Sustainable Information Systems Management. In: Hawaii International Conference on System Sciences,
S. 1–10.
Schmietendorf, A.; Dimitrov, E.; Dumke, R. R. (2002): Process models for the software development
and performance engineering tasks. In: WOSP ‘02: Proceedings of the 3rd international workshop
on Software and performance. New York, NY, USA: ACM, S. 211‐218.
Schubert, P. (2007): Business Collaboration: Fazit aus den Fallstudien. In: Wölfle, R. und Schubert, P.
(Hg.): Business Collaboration. Standortübergreifende Prozesse mit Business Software: Praxislösungen im Detail. Fallstudien, Konzepte, Modellierung. München: Hanser, S. 257–272.
Schubert, P. (2008): Business Collaboration: Erfahrungen aus der Unternehmenspraxis. In: Multikonferenz Wirtschaftsinformatik, MKWI 2008, München, 26.2.2008 - 28.2.2008, Proceedings: GITOVerlag, Berlin, S. 825–836.
Schubert, P.; Legner, C. (2011): B2B integration in global supply chains: An identification of technical
integration scenarios. In: The Journal of Strategic Information Systems 20 (3), S. 250–267.
Schubert, P.; Wölfle, R. (2007): eXperience-Methodik zur Dokumentation von Fallstudien. In: Wölfle,
R. und Schubert, P. (Hg.): Business Collaboration. Standortübergreifende Prozesse mit Business
Software: Praxislösungen im Detail. Fallstudien, Konzepte, Modellierung. München: Hanser, S. 17–
28.
Schwaber, K.; Beedle, M. (2002): Agile software development with Scrum. Upper Saddle River NJ:
Prentice Hall (Series in agile software development).
Schwarze, J. (2000): Einführung in die Wirtschaftsinformatik. 5., völlig überarb. Aufl. Herne: Verl. Neue
Wirtschafts-Briefe (NWB-Studienbücher Wirtschaftsinformatik).
Seel, C.; Vanderhaeghen, D. (2005): Meta-Model based Extensions of the EPC for InterOrganisational Process Modelling. In: 4. GI-Workshop "Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten" (EPK 2005). Hamburg, S. 117--136.
Segev, A.; Porra, J.; Roldan, M. (1997): Internet-based EDI strategy. In: Decis. Support Syst. 21 (3),
S. 157‐170.
Senger, E.; Österle, H. (2004): PROMET Business Engineering Case Studies (BECS) Version 2.0. In:
Bericht BE HSG / BECS / 1.
Shore, B. (2006): Enterprise integration - Across the globally disbursed service organization. In:
Communications of the ACM 49 (6), S. 102–106.
Shrake, S. O.; Landis, A. E.; Bilec, M. M. (2011): Greening the service industries: A case study of a
United States engineering consulting firm. In: 2011 IEEE International Symposium on Sustainable
Systems and Technology (ISSST), S. 1–6.
Sirkin, H. L.; Keenan, P.; Jackson, A. (2005): THE HARD SIDE OF CHANGE MANAGEMENT. In:
Harvard Business Review 83 (10), S. 108–118.
Smart, A. (2008): eBusiness and supply chain integration. In: Journal of Enterprise Information
Management 21 (3), S. 227–246.
Sommerlatte, T. (2005): Potenziale einer Integration von Enterprise Resource Planning und Innovationsprozess-Management. In: Ferstl, O. K., Sinz, E. J., Eckert, S. und Isselhorst, T. (Hg.): Wirtschaftsinformatik 2005: eEconomy, eGovernment, eSociety. 7. Internationale Tagung Wirtschaftsinformatik (WI 2005): Bamberg (23.-25.02.2005). Heidelberg: Physica-Verlag Heidelberg, S.
1683–1690.
Sommerville, I. (2001): Software-Engineering. 6. Aufl. München: Pearson Studium.
SPSS Inc. (2007): SPSS Base 16.0 - Benutzerhandbuch.
Stahl, B. C. (2008): The Ideology of Design: A Critical Appreciation of the Design Science Discourse in
Information Systems and Wirtschaftsinformatik. In: Becker, J., Krcmar, H. und Niehaves, B. (Hg.):
Wissenschaftstheorie und gestaltungsorientierte Wirtschaftsinformatik, Bd. 120 (Arbeitsberichte
des Instituts für Wirtschaftsinformatik, 120), S. 112–133.
Stahlknecht, P.; Hasenkamp, U. (2005): Einführung in die Wirtschaftsinformatik. Elfte, vollständig
überarbeitete Auflage. Berlin, Heidelberg: Springer Berlin Heidelberg (Springer-Lehrbuch).
256
Stemmer, M.; Holtkamp, B.; Königsmann, T. (2011): Cloud-orientierte Service-Marktplätze - Integrationsplattformen für moderne Dienstleistungen und IT-Dienste. White Paper, Dortmund. FraunhoferInstitut für Software- und Systemtechnik ISST.
Stocker, A.; Saeed, A. U.; Höfler, P.; Strohmaier, M.; Tochtermann, K. (2008): StakeholderOrientierung als Gestaltungsprinzip für Corporate Web 2.0: Eine explorative Analyse. In: Martin
Bichler, Thomas Hess, Helmut Krcmar, Ulrike Lechner, Florian Matthes, Arnold Picot et al. (Hg.):
Multikonferenz Wirtschaftsinformatik, MKWI 2008, München, 26.2.2008 - 28.2.2008, Proceedings:
GITO-Verlag, Berlin, S. 579–590.
Stolzenberg, K.; Heberle, K. (2006): Change Management. Veränderungsprozesse erfolgreich gestalten - Mitarbeiter mobilisieren. Berlin: Springer.
Strahringer, S. (2009): Nutzung interorganisationaler Informationssysteme in der Lieferkette – Einflussfaktoren und Kausalmodell. In: Wissenschaftliche Zeitschrift der Technischen Universität
Dresden 58 (1 - 2), S. 97–102.
Strahringer, S. (2012): Modell. In: Kurbel, K., Becker, J., Gronau, N., Sinz, E. und Suhl, L. (Hg.):
Enzyklopädie der Wirtschaftsinformatik – Online-Lexikon. Sechste Auflage. München: Oldenbourg.
Online verfügbar unter http://www.enzyklopaedie-der-wirtschaftsinformatik.de/, zuletzt geprüft am
23.11.2012.
Sun, W.; Zhang, X.; Guo, C. J.; Sun, P.; Su, H. (2008): Software as a Service: Configuration and
Customization Perspectives. In: Services Part II, IEEE Congress on, S. 18–25.
Sutanto, J.; Kankanhalli, A.; Tay, J.; Raman, K. S.; Tan, B. C. Y. (2008): Change Management in
Interorganizational Systems for the Public. In: Journal of Management Information Systems 25 (3),
S. 133–175.
Tan Ter Chian, F. (2010): A Perception-Based Model for Technological Innovation in Small and
Medium Enterprises. In: Alexander, P. M., Turpin, M. und van Deventer, J. P. (Hg.): 18th European
Conference on Information Systems. Pretoria: Department of Informatics, S. 1–13.
Tenhunen, M.; Penttinen, E. (2010): Assessing the Carbon Footprint of Paper vs. Electronic Invoicing.
In: ACIS 2010 Proceedings Paper 95.
Teufel, S.; Sauter, C.; Mühlherr, T.; Bauknecht, K. (1995): Computerunterstützung für die Gruppenarbeit. Bonn: Addison-Wesley.
Teuteberg, F. (2005): Realisierung ubiquitärer Supply Networks auf Basis von Auto-ID- und AgentenTechnologien - Evolution oder Revolution? In: Ferstl, O. K., Sinz, E. J., Eckert, S. und Isselhorst, T.
(Hg.): Wirtschaftsinformatik 2005: eEconomy, eGovernment, eSociety. 7. Internationale Tagung
Wirtschaftsinformatik (WI 2005): Bamberg (23.-25.02.2005). Heidelberg: Physica-Verlag Heidelberg, S. 3–22.
Thackeray, R.; Neiger, B. L. (2009): A Multidirectional Communication Model: Implications for Social
Marketing Practice. In: Health Promotion Practice 10 (2), S. 171–175.
The Boston Consulting Group (Hg.) (2009): SMART 2020 Addendum Deutschland: Die IKT-Industrie
als treibende Kraft auf dem Weg zu nachhaltigem Klimaschutz. Online verfügbar unter
http://www.gesi.org/LinkClick.aspx?fileticket=X7m82qhz%2F6o%3D&tabid=60, zuletzt geprüft am
11.02.2011.
Themistocleous, M.; Irani, Z. (2003): Integrating Cross-Enterprise Systems. An Innovative Framework
for the Introduction of Enterprise Application Integration. In: Ciborra, C. U., Mercurio, R., de Marco,
M., Martinez, M. und Carignani, A. (Hg.): Proceedings of the 11th European Conference on Information Systems. Naples, Italy, June 16-21, S. 1972–1988.
Themistocleous, M.; Irani, Z.; Peter, L. E. D. (2002): Enterprise Application Integration. An Emerging
Technology For Integrating ERP And Supply Chains. In: Wrycza, S. (Hg.): Proceedings of the 10th
European Conference on Information Systems (ECIS 2002). Information Systems and the Future of
the Digital Economy. Gdansk, Poland, June 6-8, S. 1087–1096.
Thomas, O. (2005): Das Modellverständnis in der Wirtschaftsinformatik: Historie, Literaturanalyse und
Begriffsexplikation. In: Veröffentlichungen des Instituts für Wirtschaftsinformatik 184 (1).
Thomas, O.; Leyking, K.; Dreifus, F.; Fellmann, M.; Loos, P. (2007): Serviceorientierte Architekturen:
Gestaltung, Konfiguration und Ausführung von Geschäftsprozessen. In: Veröffentlichungen des
Instituts für Wirtschaftsinformatik 189 (1).
257
Tornatzky, L. G.; Fleischer, M. (1990): The Processes of Technological Innovation. Massachusetts,
USA: Lexington Books.
Tornatzky, L. G.; Klein, K. J. (1982): Innovation characteristics and innovation adoptionimplementation: A meta-analysis of findings. In: IEEE Transactions on engineering management 29
(1), S. 28–45.
Trappey, C.; Trappey, A.; Lin, G. Y. P.; Lin, C. (2007): Business and Logistic Hub Integration to
Facilitate Global Supply Chain Linkage. In: Journal of Engineering Manufacture 221, S. 1221–
1233.
Ueltschy, L. C.; Ueltschy, M. L.; Fachinelli, A. C. (2007): The Impact of Culture on the Generation of
Trust in Global Supply Chain Relationships. In: Marketing Management Journal 17 (1), S. 15–26.
Uwizeyemungu, S.; Raymond, L. (2009): Exploring an alternative method of evaluating the effects of
ERP: a multiple case study. In: Journal of Information Technology 24 (3), S. 251–268.
Venkatesh, V. (2000): Determinants of Perceived Ease of Use: Integrating Control, Intrinsic Motivation,
and Emotion into the Technology Acceptance Model. In: Information Systems Research 11 (4), S.
342–365.
Verheyen, O. M. (2008): Energieeffizienz in Rechenzentren. In: IM Information Management & Consulting (1), S. 36–41.
Vermeulen, F. (2005): On Rigor And Relevance: Fostering Difralectic Progress in Managment Research. In: Academy of Management Journal 48 (6), S. 978‐982.
Vernadat, F. B. (2007): Interoperable enterprise systems: Principles, concepts, and methods. In:
Annual Reviews in Control 31 (1), S. 137–145.
Vinoski, S. (2002): Middleware "dark matter". In: IEEE Internet Computing 6 (5), S. 92–95.
Vlachakis, J.; Rex, S.; Otto, B.; Lebender, M.; Fleckstein, T. (2003): Web-Services: A look into quality
and security aspects: media vision expert.
Vojdani, A. F. (2003): Tools for real-time business integration and collaboration. In: IEEE Transactions
on Power Systems 18 (2), S. 555‐562.
Vrieze, P. de; Xu, L.; Bouguettaya, A.; Yang, J.; Chen, J. (2009): Process-Oriented Enterprise
Mashups. In: Grid and Pervasive Computing Conference, Workshops at the 0, S. 64–71.
Vrieze, P. de; Xu, L.; Bouguettaya, A.; Yang, J.; Chen, J. (2011): Building enterprise mashups. In:
Future Generation Computer Systems 27 (5), S. 637–642.
Vykoukal, J.; Wolf, M.; Beck, R. (2009): Does Green IT Matter? Analysis of the Relationship between
Green IT and Grid Technology from a Resource-Based View Perspective. In: PACIS 2009 Proceedings.
W3C Working Draft 28 October 2002, 2002: Web Services Description Requirements. Online verfügbar unter http://www.w3.org/TR/ws-desc-reqs/, zuletzt geprüft am 28.08.2012.
Wagner, B. A.; Fillis, I.; Johansson, U. (2003): E-business and e-supply strategy in small and medium
sized businesses (SMEs). In: Supply Chain Management: An International Journal 8 (4), S. 343–
354.
Walters, P. G. P. (2008): Adding value in global B2B supply chains: Strategic directions and the role of
the Internet as a driver of competitive advantage. In: Industrial Marketing Management 37 (1), S.
59‐68.
Wang, C.; Fergusson, C.; Perry, D.; Antony, J. (2008): A conceptual case-based model for knowledge
sharing among supply chain members. In: Business Process Management Journal 14, S. 147–165.
Waters, B. (2005): Software as a service: A look at the customer benefits. In: Journal of digital asset
management 1 (1), S. 32‐39.
Watson, R. T.; Boudreau, M.-C.; Chen, A. J. (2010): Information Systems and Environmentally
Sustainable Development: Energy Informatics and New Directions for the IS Community. In: MIS
Quarterly 34 (1), S. 23–38.
Weber, M. (2009): Von der privaten zur beruflichen Nutzung: Web-2.0-Technologien verändern
Unternehmen. In: IM Information Management & Consulting (2), S. 83–85.
258
Welker, G. A.; van der Vaart, T.; van Donk, D. P. (2008): The influence of business conditions on
supply chain information-sharing mechanisms: A study among supply chain links of SMEs. In: International Journal of Production Economics 2 (113), S. 706–720.
Wenger, E.; Snyder, W. M. (2000): Communities of Practice: The Organisational Frontier. In: Harvard
Business Review 78 (1), S. 139–145.
Weng, M.-H.; Lin, C.-Y. (2011): Determinants of green innovation adoption for small and medium-size
enterprises (SMES). In: African Journal of Business Management 5 (22), S. 9154–9163.
Wengorz, J. (2008): Strategische Kapazitätsplanung. Informationstechnologie perfektioniert Auslastung von Serverfarmen. In: IM Information Management & Consulting (1), S. 42–45.
Whitaker, J.; Mithas, S.; Krishnan, M. S. (2010): Organizational Learning and Organizational Capabilities of Firms that Engage in Onshore and Offshore Business Process Outsourcing. In: Hawaii International Conference on System Sciences, S. 1–10.
Wilde, T.; Hess, T. (2007): Forschungsmethoden der Wirtschaftsinformatik. In: Wirtschaftsinformatik
49 (4), S. 280–287.
Willcocks, L.; Lacity, M.; Fitzgerald, G. (1995): Information technology outsourcing in Europe and the
USA: Assessment issues. In: International Journal of Information Management 15 (5), S. 333–351.
Williamson, O. E. (2007): Transaction Cost Economics: An Introduction. In: Economics: The OpenAccess, Open Assessment E-Journal 1 (2007-3).
Williamson, O. E. (2008): Outsourcing: Transaction cost economics and supply chain management. In:
Journal of Supply Chain Management 44 (2), S. 5‐16.
Winter, R.; Baskerville, R. (2010): Methodik der Wirtschaftsinformatik. In: Wirtschaftsinformatik 52 (5),
S. 257–258.
Wölfle, R. (2006): Prozessexzellenz mit Business Software. In: Wölfle, R. und Schubert, P. (Hg.):
Prozessexzellenz mit Business Software. Praxislösungen im Detail : Fallstudien - Konzepte - Modellierung. München [u.a.]: Hanser, S. 5–18.
Wölfle, R. (2007): Business Collaboration - Standortübergreifende Geschäftsprozesse. In: Wölfle, R.
und Schubert, P. (Hg.): Business Collaboration. Standortübergreifende Prozesse mit Business
Software: Praxislösungen im Detail. Fallstudien, Konzepte, Modellierung. München: Hanser, S. 1–
16.
Wölfle, R.; Schubert, P. (Hg.) (2006): Prozessexzellenz mit Business Software. Praxislösungen im
Detail : Fallstudien - Konzepte - Modellierung. München [u.a.]: Hanser.
Wölfle, R.; Schubert, P. (Hg.) (2007): Business Collaboration. Standortübergreifende Prozesse mit
Business Software: Praxislösungen im Detail. Fallstudien, Konzepte, Modellierung. München: Hanser.
Wu, C. (2008): Knowledge creation in a supply chain. In: Supply Chain Management: An International
Journal 13 (3), S. 241–250.
Xu, H.; Sharma, S. K.; Hackney, R. (2005): Web services innovation research: Towards a dual-core
model. In: International Journal of Information Management 25 (4), S. 321–334.
Yang, J.; Papazoglou, M. P. (2000): Interoperation support for electronic business. In: Communications of the ACM 43 (6), S. 39‐47.
Yao, J.; Chen, S.; Wang, C.; Levy, D.; Zic, J. (2011): Modelling Collaborative Services for Business
and QoS Compliance. In: IEEE International Conference on Web Services (ICWS), S. 299–306.
Yin, R. K. (2003): Case study research. Design and methods. 3rd ed. Thousand Oaks, Calif. [u.a.]:
Sage.
Zaitun, A. B.; Zaini, Z. (2008): A web-based DSS for the evaluation of an ERP system. In: iiWAS ‘08:
Proceedings of the 10th International Conference on Information Integration and Web-based Applications & Services. New York, NY, USA: ACM, S. 698‐701.
Zelewski, S. (2007): Kann Wissenschaftstheorie behilflich für die Publikationspraxis sein? Eine
kritische Auseinandersetzung mit den "Guidelines" von Hevner et al. In: Lehner, F. und Zelewski,
S. (Hg.): Wissenschaftstheoretische Fundierung und wissenschaftliche Orientierung der Wirtschaftsinformatik. Berlin, S. 71–120.
259
Zhang, H.; Kishore, R.; Sharman, R.; Ramesh, R. (2007): Agile Integration Modeling Language
(AIML): A conceptual modeling grammar for agile integrative business information systems. In:
Decision Support Systems 44 (1), S. 266‐284.
Zhu, K.; Xu, S.; Dedrick, J. (2003): Assessing Drivers of E-Business Value: Results of a Cross-Country
Study. In: ICIS 2003 Proceedings, S. 1–13.
Zimmermann, H.-D. (2007): Elektronischer Dokumentenaustausch zwischen Unternehmen. In: Wölfle,
R. und Schubert, P. (Hg.): Business Collaboration. Standortübergreifende Prozesse mit Business
Software: Praxislösungen im Detail. Fallstudien, Konzepte, Modellierung. München: Hanser, S.
127–134.
Zimmermann, O.; Schlimm, N.; Waller, G.; Pestel, M. (2005): Analysis and Design Techniques for
Service-Oriented Development and Integration. In: IBM Deutschland.
Zinkernagel, A. (2001): Partizipative Entwicklung von Mensch - Maschine - Systemen. Online verfügbar unter http://www3.psychologie.hu-berlin.de/ingpsy/alte%20Verzeichnisse%20%20Arb1/Lehrveranst/seminar/psych_technik/partizipation_01/, zuletzt aktualisiert am 17.06.2001,
Zwikael, O.; Smyrk, J. (2011): Project Management for the Creation of Organisational Value. London:
Springer-Verlag London Limited.
260
Anhänge
Anhänge
Anhang A: Fragebogen zur explorativen Studie
Herzlich willkommen zur Umfrage bezüglich betrieblicher Integration.
Die Umfrage wird im Zuge des Projekts „GuideBIS - Guidance Model for Business Integration“ von der FH Steyr durchgeführt.
Ziel ist es, die Themen-Relevanz betrieblicher Integration zu ermitteln und folglich den
aktuellen Integrationsbedarf Ihres Unternehmens einschätzen zu können.
Die Beantwortung der Fragen wird etwa 10 bis 15 Minuten in Anspruch nehmen.
Bitte klicken Sie auf „Weiter“, um die Befragung zu starten!
Wir danken Ihnen für Ihre Mitarbeit!
--Unternehmensgröße? Geben Sie die Anzahl der Mitarbeiter in Ihrem Unternehmen an.
1 - 9 Mitarbeiter
10 - 49 Mitarbeiter
50 - 249 Mitarbeiter
250 - 999 Mitarbeiter
mehr als 1000 Mitarbeiter
Welchem Wirtschaftszweig ist Ihr Unternehmen zuzuordnen?
Rohstofflieferant
Industrie
Großhandel
Einzelhandel
Dienstleister
Sonstige
Welche Produktsegmente tragen maßgeblich zur Wertschöpfung in Ihrem Unternehmen bei? Mehrfachnennung möglich (max. 5 Kategorien).
Handel
Unternehmensnahe Dienstleistung
Lebensmittel / Getränke
Nonfood (Kosmetik, Wasch-Putz-Reinigungsmittel, Haushaltswaren usw.)
Textil / Schuhe / Sport
Anhänge
261
Informationstechnologie (IT) / Elektronik
Telekommunikation
Chemie / Pharma
Gesundheit / Medizin
Gummi / Kunststoff
Bauen / Wohnen / Garten
Fahrzeugbau
Elektro / Feinmechanik
Maschinen- / Anlagenbau
Metallerzeugung / -verarbeitung
Büromaschinen / Datenverarbeitung
Papier
Tourismus
Energie- / Wasserversorgung
Sonstige
--In welchem geografischen Gebiet unterhält Ihr Unternehmen Geschäftsbeziehungen?
innerhalb Österreichs
EU-weit
europaweit
weltweit
Welche der folgenden Beschreibungen trifft am ehesten auf die Zusammensetzung
Ihrer Kunden und Lieferanten zu?
Viele Geschäftspartner aus vielen Branchen
Viele Geschäftspartner aus wenigen Branchen
Wenige Geschäftspartner aus vielen Branchen
Wenige Geschäftspartner aus wenigen Branchen
Wie hoch ist die geschätzte Anzahl Ihrer Geschäftspartner?
weniger als 10 Geschäftspartner
10 - 100 Geschäftspartner
100 - 1.000 Geschäftspartner
mehr als 1.000 Geschäftspartner
--Diese Seite enthält grundlegende Fragen zur Informations- und KommunikationsTechnologie (IKT) im Unternehmen, welche die Voraussetzung zur Integration der Hard- und
Softwarekomponenten im Unternehmen darstellen.
Verbindungstechnik der Internet-Verbindung?
Breitband (DSL, Satellit, Kabel, Funk, Mobile-UMTS)
262
Anhänge
ISDN
Modem
Mobile (GPRS)
Kein Zugang zum Internet vorhanden
Anzahl Computerarbeitsplätze gesamt? Geben Sie in etwa an wieviel Prozent der Arbeitsplätze in Ihrem Unternehmen ausgestattet mit Computer (PC, Laptop) sind.
bis 10%
bis 50%
bis 90%
mehr als 90%
Anzahl Computerarbeitsplätze mit Internetverbindung?
bis 10%
bis 50%
bis 90%
mehr als 90%
Welche der folgenden Netzwerke setzen Sie im Unternehmen ein? Mehrfachnennung
möglich.
Intranet (Unternehmensinternes Netzwerk)
Extranet (Externes, nicht öffentliches Netzwerk mit Kunden/Partnern)
LAN (Lokales Netzwerk innerhalb des Unternehmens z.B. über Ethernet)
WLAN (Wireless LAN, Funk-Netzwerk innerhalb des Unternehmens)
--Welche der folgenden Strategien/Richtlinien im IKT-Bereich gibt es in Ihrem Unternehmen? Mehrfachnennung möglich.
Schriftliche e-Business Strategie
Schriftliche Richtlinien zur Handhabung sensibler Daten
Schriftliche Richtlinien zur Nutzung von Internet, E-Mail
Schriftliche Richtlinien zur Nutzung serviceorientierter Architektur (SOA, Web-Services,
SaaS)
Schriftliche Richtlinien zum Softwareeinsatz auf PCs
Schriftliche Richtlinien zum Einsatz von Verschlüsselung und elektronischen Signaturen
Schriftliche Richtlinien zur Nutzung mobiler Endgeräte (Notebooks, PDAs)
Schriftliche Richtlinien zur Nutzung mobiler Speicher (USB-Sticks)
Schriftliche Maßnahmen zur Informationssicherheit
Schriftliches Schulungs- und Weiterbildungskonzept
Sonstige
Anhänge
263
Welche der folgenden Anwendungen/Lösungen werden in ihrem Unternehmen eingesetzt? Geben Sie zu jeder Anwendung/Lösung an ob diese im Einsatz ist (Ja), nicht im
Einsatz ist (Nein) oder sich in Planung befindet (Geplant)
Eigene Homepage
Eigener Online-Shop
Customer Relationship Management (CRM)
Elektronische Rechnungslegung
Artikelstammdatenverwaltung
Elektronischer Katalog
Elektronisches Marketing
Software für Logistik / Lagerhaltung
Sortimentsmanagement
Elektronische Beschaffung (e-Procurement)
Benutzung von elektronischen (B2B) Marktplätzen
Elektronischer Datenaustausch (EDIFACT, XML, ...)
--Ist in Ihrem Unternehmen ein IT Verantwortlicher vorhanden?
Ja
Nein
Wie hoch ist das geschätzte Budget für Investitionen in die IT im nächsten Jahr in
Prozent? Wie viel % vom Gesamtbudget ist für die IT veranschlagt. Geben Sie eine Zahl
von 0 bis 99 ein. z.B. 0... kein Budget für IKT vorhanden. 5... 5% vom Gesamtbudget ist für
IT veranschlagt.
Welche der folgenden Geschäftsbereiche haben Sie outgesourct? Thema: Outsourcing.
Markieren Sie hier jene Geschäftsbereiche, die Sie an Drittunternehmen ausgelagert haben.
Mehrfachnennung möglich.
Beschaffung/Einkauf/Lager
Verkauf/Vertrieb
Rechnungslegung
Marketing/Kundenbindung
Produktentwicklung
Produktion
Lohnverrechnung
Buchhaltung
Controlling (Steuerberater)
Service/Wartung
Sonstige
---
264
Anhänge
Welche der folgenden Sicherheits-Lösungen setzen Sie zum Schutz (der Daten) Ihres
Unternehmens ein? Mehrfachnennung möglich.
Anti-Viren-Software
Firewall
SSL, Zertifikate
Intrusion Detection / Prevention Software
Backup/Datensicherung
Spiegelung der Festplatten (RAID-System) der Server
Digitale Signatur (E-Mail, Web)
Verschlüsselung (Daten, Kommunikation)
Langzeit-Archivierung
Physische Sicherheit (Zutrittskontrolle, Überwachung)
Ausfallsystem (Doppelte Anbindung, Ausfall-Server)
Sonstige
Sind bereits Angriffe auf die Sicherheit Ihres Unternehmens aufgetreten? Wenn ja,
welche? Mehrfachnennung möglich.
Malware (Virus, Trojanisches Pferd, Wurm, usw.)
Phishing (Abfischen von TANs, Passwörtern)
Online-Angriff (Hacking, Backdoors, DoS-Attacke)
Abhören von Kommunikation (E-Mail, FTP, VoIP)
Einbruch in Gebäude
Verlust/Diebstahl mobiler Systeme (Notebook, PDA)
Verlust/Diebstahl von Speichermedien (USB-Stick, CD, DVD, Backup)
Sonstige
--Wie schätzen Sie die Informationssicherheit in Ihrem Unternehmen ein? Bewerten Sie
die einzelnen Fragen nach dem Schulnotensystem 1 (sehr gut), 2 (gut), 3 (befriedigend), 4
(ausreichend), 5 (nicht ausreichend), keine Angabe.
Rechenzentrum/Serverraum
Server (Hardware, Software, Daten)
Computerarbeitsplätze (PCs)
Telearbeitsplätze
Mobile Endgeräte (Notebook, PDA)
Speichermedien (CDs, DVDs, USB-Sticks, Tapes)
Netzwerk verkabelt (Ethernet)
Netzwerk drahtlos (WLAN, UMTS)
Applikationen/Anwendungen
Daten
---
Anhänge
265
Über welche Wege läuft die Kommunikation mit Ihren Lieferanten derzeit? Schätzen Sie
bitte zu wie viel Prozent Sie mit welchem Mittel mit Ihren Lieferanten kommunizieren. Die
Summe muss 100 % ergeben.
% per Telefon
% persönliches Gespräch
% per E-Mail
% per Fax
% per sonst. elektr. Datenaustausch
Über welche Wege läuft die Kommunikation mit Ihren Kunden derzeit? Schätzen Sie
bitte zu wie viel Prozent Sie mit welchem Mittel mit Ihren Kunden kommunizieren. Die Summe muss 100 % ergeben.
% per Telefon
% persönliches Gespräch
% per E-Mail
% per Fax
% per sonst. elektr. Datenaustausch
--Wofür nutzen Sie in Ihrem Unternehmen eindeutige Nummerierungen? Mehrfachnennung möglich.
Kunden-Identifikation
Lieferanten- Identifikation
Artikel-Identifikation
Identifikation von Packstücken (z.B. Paletten)
Transaktionsdaten-Identifikation
Wir verwenden keine Nummern
Sonstige
Welche Nummern nutzen Sie? Mehrfachnennung möglich.
Internationale Lokationsnummer (ILN)
Internationale Artikelnummer (EAN)
Nummer der Versandeinheit (NVE)
Interne Kunden-/Lieferanten-Nummern
Externes Kunden-/Lieferanten-Nummernsystem (Fremd-Nummernsystem)
Weiß nicht
Sonstige
Wie liegen in Ihrem Unternehmen die Stammdaten vor, die Ihre Kunden/Artikel/usw.
näher beschreiben? Mehrfachnennung möglich.
Word-, PDF- oder andere Textformate
Excel, CSV- oder andere Tabellenformate
In einer Datenbank
266
Anhänge
In einem Enterprise Resource Planning (ERP) System / Warenwirtschaftssystem
Externer Datenpool (z.B. SINFOS)
Sonstige
Welche der folgenden Aussagen zu Stammdaten trifft auf Sie zu/trifft nicht zu? Bewerten Sie die einzelnen Aussagen nach dem Schulnotensystem (1… Triff voll und ganz zu; 5…
Trifft nicht zu).
Es existieren schriftliche Regeln zur Stammdateneingabe.
Stammdaten werden regelmäßig auf Konsistenz überprüft.
Stammdaten werden regelmäßig mit jenen von Geschäftspartnern abgeglichen.
--Welche der folgenden E-Business Standards/Klassifikationen kennen Sie bzw. sind in
Ihrem Unternehmen im Einsatz? (Unbekannt, Ist bekannt, Ist bekannt und wird eingesetzt)
openTRANS
cXML
UBL (vormals xCBL)
UN/EDIFACT
OBI
BMEcat
eCl@ss
ETIM
ProfiCl@ss
UNSPSC
ebXML
RosettaNet
eCO
--Führen Sie bereits überbetrieblichen elektronischen Datenaustausch (dh. eine betriebliche Integration) mit Geschäftspartnern durch?
Ja
Nein
Geplant
--Was wären/sind Ihrer Meinung nach die Anforderungen an eine effektive betriebliche
Integration? Mehrfachnennung möglich.
Beschleunigung der Geschäftsprozesse
Anpassung an Kundenwünsche
Erfüllung von Lieferantenanforderungen
Qualitätsverbesserungen
Interne Produktivitätsverbesserungen
Anhänge
267
Kostensenkungen
Umsatzsteigerung
Sonstige
--Für welche Geschäftsbereiche existiert bereits eine betriebliche Integration? Mehrfachnennung möglich.
Verkauf/Vertrieb
Rechnungslegung
Produktentwicklung
Produktionsabläufe
Innerbetriebliche Verwaltung/Personalwesen
Buchhaltung
Unternehmensführung (Kennzahlen für Unternehmen/Markt, ManagementInformationssystem)
Service/Wartung
Sonstige
Was wollten Sie mit der betrieblichen Integration erreichen? Mehrfachnennung möglich.
Beschleunigung der Geschäftsprozesse
Kostensenkungen
Umsatzsteigerung
Sonstige
Wurden die definierten Ziele der Integration erreicht?
Ja.
Nein.
Teilweise, folgende Ziele wurden nicht erreicht:
Welche der folgenden Medien/Formate nutzen Sie für den elektronischen Austausch
von Daten mit Geschäftspartnern? Mehrfachnennung möglich.
Datenträger (z.B. USB-Stick, Disk, CD, DVD, Magnetband)
EDI-Netz (z.B. EDIFACT)
E-Mail
Datenaustausch über HTTP
Datenaustausch über FTP
268
Anhänge
XML-Datenaustausch
Web Service
Sonstige
--Welche Konzepte zur betrieblichen Integration sind für Ihr Unternehmen interessant/relevant? Bewerten Sie die einzelnen Konzepte nach dem Schulnotensystem (1… sehr
interessant, 5… nicht interessant; Konzept nicht bekannt).
Integration auf Ebene von Enterprise Resource Planning Systemen (ERP, z.B. SAP iDoc)
Integration auf Ebene der Daten (z.B. XML, EDI)
Integration auf Ebene der Geschäftsprozesse (z.B. Einbindung externer Prozessunterstützung)
Integration durch kommunikative Technologie (z.B. RFID)
Integration durch Aufhebung von Medienbrüchen (z.B. elektronische Rechnungen oder
Lieferscheine)
Überbetriebliche Supply Chain Integration (z.B. unternehmensübergreifende Einkaufsportale)
Business Rules auf organisatorischer und operativer Ebene (z.B. implementierte Geschäftsregeln in SAP)
Integration mittels Integrations-Software (z.B. Microsoft BizTalk Server)
Integration auf Ebene von Services (z.B. Web Services)
--Beschäftigt sich Ihr Unternehmen bereits mit SOA (Service Orientierte Architektur)?
Nein
Nur informativ
Erste Projekte sind initiiert
Erste Projektphasen sind bereits abgeschlossen
SOA ist bereits weitestgehend umgesetzt
--Haben Sie im letzten Jahr in Ihrem Unternehmen neue Prozesse, Produkte oder Services eingeführt?
Ja, mittels IKT.
Ja, allerdings ohne IKT.
Nein.
Wie schätzen Sie den Einfluss von IKT in Ihrem Unternehmen auf folgende Bereiche
ein? Beurteilen Sie nach dem Schulnotensystem (1... sehr hoch, 5... kein Einfluss). Dh.
wenn Sie z.B. bei Produktivität "1" angeben, wird Ihrer Meinung nach durch IKT die Produktivität im Unternehmen maßgeblich erhöht.
Produktivitätssteigerung
Schaffung von Arbeitsplätzen
Erhöhung der Effizienz des gesamten Unternehmens
Anhänge
269
Steigerung der globalen Wettbewerbsfähigkeit
Beitrag zum Umweltschutz
--In welcher Abteilung sind Sie beschäftigt?
Geschäftsführung
IT-/EDV-Abteilung
Qualitätssicherung
Konstruktion/Entwicklung
Produktion/Fertigung
Einkauf
Verkauf
Marketing
Sonstige
Welche Position bekleiden Sie innerhalb Ihrer Abteilung?
Abteilungsleiter
Bereichsleiter
Mitarbeiter
Sonstige
Möchten Sie über das Ergebnis der Befragung informiert werden?
Ja
Nein
--Die Befragung wird anonym durchgeführt, wenn Sie über das Ergebnis informiert werden
möchten, bitten wir Sie die nachfolgenden Kontaktdaten einzugeben.
Name des Unternehmens
Ansprechperson
Straße
PLZ
Ort
E-Mail
--Sollten Sie etwas vermisst haben oder möchten Sie uns über die Fragen hinaus etwas
mitteilen: Wir freuen uns über jede Anregung!
270
Anhänge
Anhang B: Tabellarische Auswertungsergebnisse
Tabelle 15: Führen Sie bereits überbetrieblichen elektronischen Datenaustausch (dh. eine betriebliche
Integration) mit Geschäftspartnern durch?
Ja
Unternehmensgröße laut
Geplant
Nein
Gesamt (N)
EU
1-49 Mitarbeiter
50-249 Mitarbeiter
über 250 Mitarbeiter
Anzahl
6
7
22
%
25,0%
46,7%
71,0%
Anzahl
2
4
4
Gesamt
35
50,0%
10
Codierung der Antworten: Ja = 1, Geplant = 3, Nein = 5
%
8,3%
26,7%
12,9%
Anzahl
16
4
5
%
66,7%
26,7%
16,1%
14,3%
25
35,7%
Anzahl
24
15
31
70
Tabelle 16: Korrelation Unternehmensgröße und überbetrieblicher elektronischer Datenaustausch.
Führen Sie bereits überbetrieblichen elektronischen
Datenaustausch (dh. eine betriebliche Integration) mit
Geschäftspartnern durch?
Unternehmensgröße laut EU
Korrelationskoeffizient
-,459(**)
Sig. (2-seitig)
,000
N
56
** Die Korrelation ist auf dem 0,01 Niveau signifikant (zweiseitig).
Tabelle 17: Welche der folgenden Strategien/Richtlinien im IKT-Bereich gibt es in Ihrem Unternehmen? (Mehrfachnennung möglich)
50-249
über 250
Mitarbeiter
Mitarbeiter
AnAn%
zahl
%
zahl
1-49 Mitarbeiter
An%
zahl
Gesamt
An%
zahl
Schriftliche e-Business
Strategie
16,1%
5
8,3%
2
33,3%
16
22,3%
23
38,7%
12
58,3%
14
66,7%
32
56,3%
58
Schriftliche Richtlinien zur Nutzung
von Internet, E-Mail
38,7%
12
58,3%
14
66,7%
32
56,3%
58
serviceorientierter Architektur
(SOA, Web Services, SaaS)
6,5%
2
0,0%
0
12,5%
6
7,8%
8
19,4%
6
62,5%
15
66,7%
32
51,5%
53
Schriftliche Richtlinien zum Einsatz
von Verschlüsselung und elektronischen Signaturen
0,0%
0
12,5%
3
39,6%
19
21,4%
22
mobiler Endgeräte (Notebooks,
PDAs)
9,7%
3
29,2%
7
56,3%
27
35,9%
37
mobiler Speicher (USB-Sticks)
9,7%
3
4,2%
1
35,4%
17
20,4%
21
Schriftliche Richtlinien zum
Softwareeinsatz auf PCs
Anhänge
271
Schriftliche Maßnahmen zur
Informationssicherheit
25,8%
8
54,2%
13
56,3%
27
46,6%
48
Schriftliches Schulungs- und
Weiterbildungskonzept
16,1%
5
62,5%
15
45,8%
22
40,8%
42
Verarbeitete Fälle: Eingeschlossen N=103, Ausgeschlossen N=22, Gesamt N=125
Tabelle 18: Korrelation Unternehmensgröße und Strategien/Richtlinien im IKT-Bereich
Schriftliche e-Business Strategie
Sig. (2-seitig)
N
Schriftliche Richtlinien zur Nutzung von Internet, E-Mail
Schriftliche Richtlinien zur Nutzung serviceorientierter
Architektur (SOA, Web Services, SaaS)
Schriftliche Richtlinien zum Softwareeinsatz auf PCs
Sig. (2-seitig)
,018
103
,221(*)
N
Sig. (2-seitig)
,018
N
103
,116
Sig. (2-seitig)
,216
N
103
Sig. (2-seitig)
N
Sig. (2-seitig)
N
Schriftliche Richtlinien zur Nutzung mobiler Speicher (USBSticks)
Schriftliche Maßnahmen zur Informationssicherheit
103
,405(**)
,000
103
,400(**)
,000
103
,291(**)
,002
103
,230(*)
,014
103
,202(*)
Sig. (2-seitig)
,031
N
103
* Die Korrelation ist auf dem 0,05 Niveau signifikant (zweiseitig).
Tabelle 19: Ist in Ihrem Unternehmen ein IT Verantwortlicher vorhanden?
% (Ja)
,000
N
N
1-49 Mitarbeiter
50-249 Mitarbeiter
Gesamt
,358(**)
Sig. (2-seitig)
Sig. (2-seitig)
Schriftliches Schulungs- und Weiterbildungskonzept
103
,221(*)
N
Schriftliche Richtlinien zur Nutzung mobiler Endgeräte
(Notebooks, PDAs)
,038
Sig. (2-seitig)
Schriftliche Richtlinien zum Einsatz von Verschlüsselung
und elektronischen Signaturen
EU
,195(*)
Anzahl (Ja)
64,3%
28
86,4%
22
92,7%
41
82,4%
91
272
Anhänge
Tabelle 20: Korrelation Unternehmensgröße und IT Verantwortlicher
Ist in Ihrem Unternehmen ein IT
Verantwortlicher vorhanden?
EU
,290(**)
,004
91
Sig. (2-seitig)
N
Tabelle 21: Welche der folgenden Geschäftsbereiche haben Sie outgesourct? (Mehrfachnennung
möglich)
über 250 Mi50-249 Mitarbeiter
tarbeiter
1-49 Mitarbeiter
Gesamt
Anzahl
2
%
7,1%
Anzahl
1
%
4,5%
Anzahl
3
%
7,3%
Anzahl
6
%
6,6%
Verkauf/Vertrieb
2
7,1%
0
0,0%
1
2,4%
3
3,3%
Rechnungslegung
1
3,6%
0
0,0%
2
4,9%
3
3,3%
2
7,1%
0
0,0%
0
0,0%
2
2,2%
Produktentwicklung
0
0,0%
0
0,0%
1
2,4%
1
1,1%
Produktion
1
3,6%
1
4,5%
2
4,9%
4
4,4%
Lohnverrechnung
13
46,4%
6
27,3%
7
17,1%
26
28,6%
Buchhaltung
9
32,1%
2
9,1%
2
4,9%
13
14,3%
9
32,1%
4
18,2%
2
4,9%
15
16,5%
Service/Wartung
9
32,1%
4
18,2%
14
34,1%
27
29,7%
Sonstige
2
7,1%
3
13,6%
2
4,9%
7
7,7%
Verarbeitete Fälle: Eingeschlossen N=91 (1-49 Mitarbeiter: N=28, 50-249 Mitarbeiter: N=22, über 250 Mitarbeiter:
N=41), Ausgeschlossen N=34, Gesamt N=125
Tabelle 22: Korrelation Unternehmensgröße und Outsourcing von Geschäftsbereichen.
Sig. (2-seitig)
N
Verkauf/Vertrieb
Sig. (2-seitig)
N
Rechnungslegung
91
,658
91
-,183
,067
91
,102
Sig. (2-seitig)
,306
N
91
,025
Sig. (2-seitig)
,803
N
Lohnverrechnung
,364
Sig. (2-seitig)
N
Produktion
91
-,091
,044
Sig. (2-seitig)
Produktentwicklung
,925
N
,009
Sig. (2-seitig)
91
-,258(**)
,010
Anhänge
273
N
Buchhaltung
91
-,300(**)
Sig. (2-seitig)
,003
N
91
-,298(**)
Sig. (2-seitig)
,003
N
Service/Wartung
91
,038
Sig. (2-seitig)
,705
N
Sonstige
91
-,052
Sig. (2-seitig)
,603
N
91
Tabelle 23: Welche der folgenden Anwendungen/Lösungen werden in ihrem Unternehmen eingesetzt?
Ja
Eigene Homepage
Eigener Online-Shop
Elektronischer Datenaustausch (EDIFACT,
XML, ...)
1-49 Mitarbeiter
50-249 Mitarbeiter
Gesamt
1-49 Mitarbeiter
50-249 Mitarbeiter
Gesamt
1-49 Mitarbeiter
50-249 Mitarbeiter
Gesamt
1-49 Mitarbeiter
50-249 Mitarbeiter
Gesamt
1-49 Mitarbeiter
50-249 Mitarbeiter
Gesamt
1-49 Mitarbeiter
50-249 Mitarbeiter
Gesamt
1-49 Mitarbeiter
50-249 Mitarbeiter
Gesamt
1-49 Mitarbeiter
50-249 Mitarbeiter
Gesamt
1-49 Mitarbeiter
50-249 Mitarbeiter
Geplant
9
22
38
69
6
10
27
43
10
12
26
48
28
24
47
99
3
7
13
23
7
9
32
48
11
16
33
60
9
15
39
63
7
13
21
1
0
4
5
1
3
4
8
5
3
11
19
1
0
1
2
2
2
1
5
0
3
5
8
2
1
8
11
0
3
3
6
1
1
4
Nein
20
2
6
28
23
11
17
51
15
9
11
35
1
0
0
1
25
15
34
74
23
12
11
46
17
7
7
31
21
6
6
33
22
10
23
274
Anhänge
Gesamt
1-49 Mitarbeiter
50-249 Mitarbeiter
Gesamt
Enterprise Resource Planning (ERP) System /
1-49 Mitarbeiter
Warenwirtschaftssystem
50-249 Mitarbeiter
Gesamt
1-49 Mitarbeiter
50-249 Mitarbeiter
Gesamt
1-49 Mitarbeiter
50-249 Mitarbeiter
Gesamt
41
11
10
22
43
6
18
35
59
6
19
39
64
4
6
17
27
6
1
4
2
7
1
1
1
3
1
0
0
1
1
0
4
5
55
18
10
24
52
23
5
12
40
23
5
9
37
25
18
27
70
Tabelle 24: Korrelation Unternehmensgröße und eingesetzte E-Business Anwendungen.
Eigene Homepage
Eigener Online-Shop
Sig. (2-seitig)
,341
N
102
,080
N
102
N
Sig. (2-seitig)
N
Sig. (2-seitig)
N
,002
102
-,385(**)
,000
102
-,160
102
N
Sig. (2-seitig)
N
102
-,285(**)
,082
Sig. (2-seitig)
,029
N
N
-,196(*)
Sig. (2-seitig)
Sig. (2-seitig)
-,162
Sig. (2-seitig)
Sig. (2-seitig)
EU
-,089
-,069
,452
102
-,461(**)
,000
102
-,390(**)
,000
102
-,231(*)
Sig. (2-seitig)
,012
N
102
-,407(**)
Anhänge
275
Sig. (2-seitig)
,000
N
102
Elektronischer Datenaustausch (EDIFACT, XML, ...)
-,311(**)
Sig. (2-seitig)
,001
N
102
-,443(**)
Sig. (2-seitig)
,000
N
102
* Die Korrelation ist auf dem 0,05 Niveau signifikant (zweiseitig).
Tabelle 25: Welche der folgenden E-Business Standards/Klassifikationen kennen Sie bzw. sind in
Ihrem Unternehmen im Einsatz?
Unbekannt
Anzahl
Ist bekannt und wird
eingesetzt
Ist bekannt
%
Anzahl
%
Anzahl
%
openTRANS
52
74,3%
17
24,3%
1
1,4%
cXML
44
62,9%
20
28,6%
6
8,6%
UBL (vormals xCBL)
55
78,6%
15
21,4%
0
,0%
UN/EDIFACT
27
38,6%
25
35,7%
18
25,7%
OBI
55
78,6%
14
20,0%
1
1,4%
BMEcat
55
78,6%
15
21,4%
0
,0%
eCl@ss
53
75,7%
15
21,4%
2
2,9%
ETIM
56
80,0%
12
17,1%
2
2,9%
ProfiCl@ss
58
82,9%
11
15,7%
1
1,4%
UNSPSC
55
78,6%
15
21,4%
0
,0%
ebXML
54
77,1%
12
17,1%
4
5,7%
RosettaNet
49
70,0%
19
27,1%
2
2,9%
eCO
57
81,4%
12
17,1%
1
1,4%
Tabelle 26: Korrelation Unternehmensgröße und E-Business Standards/Klassifikationen
Unternehmensgrösse laut EU
Welche der folgenden E-Business Standards/Klassifikationen
kennen Sie bzw. sind in Ihrem Unternehmen im Einsatz?:
openTRANS
Sig. (2-seitig)
N
kennen Sie bzw. sind in Ihrem Unternehmen im Einsatz?: cXML
kennen Sie bzw. sind in Ihrem Unternehmen im Einsatz?: UBL
(vormals xCBL)
-,028
,806
70
,056
Sig. (2-seitig)
N
,612
70
,025
Sig. (2-seitig)
,823
N
70
UN/EDIFACT
,194
Sig. (2-seitig)
,072
kennen Sie bzw. sind in Ihrem Unternehmen im Einsatz?: OBI
,105
Sig. (2-seitig)
,356
N
70
276
Anhänge
N
70
BMEcat
,215
Sig. (2-seitig)
,059
eCl@ss
,031
Sig. (2-seitig)
,780
kennen Sie bzw. sind in Ihrem Unternehmen im Einsatz?: ETIM
,043
Sig. (2-seitig)
,705
N
70
N
70
N
70
ProfiCl@ss
,046
Sig. (2-seitig)
,688
UNSPSC
,025
Sig. (2-seitig)
,823
kennen Sie bzw. sind in Ihrem Unternehmen im Einsatz?: ebXML
,034
Sig. (2-seitig)
,759
N
70
N
70
N
70
RosettaNet
,022
Sig. (2-seitig)
,848
kennen Sie bzw. sind in Ihrem Unternehmen im Einsatz?: eCO
,039
Sig. (2-seitig)
,733
N
70
N
70
Tabelle 27: Was wären/sind Ihrer Meinung nach die Anforderungen an eine effektive betriebliche
Integration? („Nein” oder „Geplant”); Was wollten Sie mit der betrieblichen Integration erreichen? („Ja“)
50-249
über 250
Mitarbeiter
Mitarbeiter
1-49 Mitarbeiter
%
Betriebliche
Integration
„Nein” oder
„Geplant”
%
Anzahl
%
Anzahl
%
Anzahl
Beschleunigung der
Geschäftsprozesse
66,7
10
50,0
3
100,0
7
71,4
20
26,7
4
33,3
2
57,1
4
35,7
10
13,3
2
16,7
1
42,9
3
21,4
6
40,0
6
66,7
4
42,9
3
46,4
13
33,3
5
33,3
2
42,9
3
35,7
10
Kostensenkungen
60,0
9
66,7
4
71,4
5
64,3
18
Umsatzsteigerung
13,3
2
16,7
1
28,6
2
17,9
5
Sonstige
13,3
2
7,1
2
N: „Nein” oder „Geplant”
Betriebliche
Integration „Ja”
Anzahl
Gesamt
15
6
7
28
Beschleunigung der
Geschäftsprozesse
80,0
4
100,0
4
100,0
16
96,0
24
40,0
2
50,0
2
56,3
9
52,0
13
20,0
1
25,0
1
37,5
6
32,0
8
40,0
2
75,0
3
56,3
9
56,0
14
Anhänge
277
Kostensenkungen
20,0
1
75,0
3
68,8
11
60,0
15
80,0
4
50,0
2
68,8
11
68,0
17
25,0
1
25,0
4
20,0
5
Umsatzsteigerung
Sonstige
N: „Ja”
5
4
Tabelle 28: Wurden die definierten Ziele der Integration erreicht?
Anzahl
Ja
Teilweise
Nein
29
Prozent
85,3
5
14,7
0
0,0
16
25
278
Anhänge
Anhang C: Struktur für Fallstudien mit Fragen für Interviews
Das Unternehmen
Allgemeines (wesentliche Meilensteine in der Historie des Unternehmens)
Rechtsform (Eigentümerstruktur; ggf. Einbettung in einen Konzern)
Unternehmensorganisation (organisatorische Gliederung der wichtigste Abteilungen bzw.
Geschäftsprozesse)
Geschäftsfelder (wichtigste Geschäftsfelder, wichtigste Mitbewerber je Geschäftsfeld, wichtigste Kunden u. Lieferanten je Geschäftsfeld)
Zahlen und Fakten (Umsatz insgesamt und Verteilung auf die Geschäftsfelder, Gewinn,
Marktanteile je Geschäftsfeld; Marktanteile der Mitbewerber, Marktwachstum)
Der Auslöser des Projekts
Was sind die Auslöser für die angestrebte Veränderung? (Technologische Faktoren, Organisatorische Faktoren, Faktoren aus dem betrieblichen Umfeld; z.B. kundenseitige oder lieferantenseitige, unternehmensinterne oder -externe Auslöser; Liegt der Auslöser in Produktinnovation / Prozessinnovation / Änderung der rechtlichen Rahmenbedingungen / Marktveränderung / etc.)
Welche Ziele werden mit der Veränderung angestrebt? (Rationalisierung, Verbesserung der
Abläufe, etc.)
Ausgangssituation vor Implementierung des Projekts
Geschäftssicht, Geschäftsmodell: Warum ist das Vorhaben aus finanzieller Sicht relevant?
(Beschreibung des Geschäftsmodells)
Prozesssicht: Welche Prozesse sind relevant? (Beschreibung der Ist-Prozesse im relevanten
Unternehmensbereich)
Technische Sicht, Anwendungssicht: Welche Systeme sind relevant? (Beschreibung der
Informationsinfrastruktur; Beschreibung der relevanten Applikationslandschaft Standard- und
Individuallösungen, Schnittstellen; Beschreibung der Hardware-Architektur)
Marketingsicht: Welche Zielgruppen, Märkte will man erreichen? (Positionierung am Markt)
Anhänge
279
Alternative Lösungsansätze
Welche grundsätzlichen Lösungsmöglichkeiten gibt es und welche davon wird ausgewählt
und warum? (Grobe Beschreibung möglicher Lösungsansätze)
Lösung
Vorgehensweise zur Umsetzung, Projektmanagement: Wie waren die zeitlichen Rahmenbedingungen? Wer waren die beteiligten Personen (intern, extern)? Wie war das Projekt organisiert? (Beschreibung des Projekts inkl. Phasen und Meilensteine)
Geschäftssicht, Geschäftsmodell: Werden neue Geschäftsfelder erschlossen? Sollen Lücken
im Produkt-/Dienstleistungsportfolio geschlossen werden?
Prozesssicht: Werden der Prozesse verändert? Werden neue Prozesse eingeführt? Werden
Prozesse eliminiert bzw. ausgelagert? (beispielsweise Substitution von Teilprozessen durch
elektronische Abwicklung, Verlagerung von Aufgaben zu Partnern in der Wertschöpfung)
Technische Sicht, Anwendungssicht: Welche Änderungen hat es in der Informationsinfrastruktur gegeben? (Beschreibung der relevanten Applikationslandschaft, Standard- und
Individuallösungen, Schnittstellen, Beschreibung der Änderungen der Hardware-Architektur)
Marketingsicht: Welche Änderungen gab es in Bezug auf Zielgruppen, Märkte, Positionierung?
Beurteilung der Wirtschaftlichkeit: Welcher quantifizierbare Nutzen ist entstanden? (Beschreibung der Kosten des Projekts und des quantitativen Nutzens, z.B. durch Prozessverkürzung, Lagerstandsreduktion, etc.)
Fazit
Was hätte anders/besser laufen können? (Lessons Learned, Erfolgsfaktoren)
Was wären logische Folgeaktivitäten? (Ausblick)
280
Anhänge
Anhang D: Interviewleitfaden für die Workshops in den Pilotprojekten
Identifikation eines Prozesses
Nachfolgende Prozesse werden als wissensintensive Prozesse angesehen. Ein Prozess für
die Skizzierung mittels Kärtchen und anschließende Diskussion ist auszuwählen.
(Einfügen der relevanten Prozesse, markieren des ausgewählten Prozesses im Workshop)
Qualitatives Experteninterview
(Für den identifizierten und skizzierten Prozess sind die nachfolgenden Fragen in einer
gemeinsamen Diskussionsrunde zu beantworten.)
Kommunikation
Wie verständigen Sie sich im identifizierten Prozess in den Teams untereinander? (Telefonisch, E-Mail, Skype, persönliches Gespräch)
Welche Hilfsmittel zur Kommunikation stehen Ihnen hierfür zur Verfügung? Welche nutzen
Sie tatsächlich und wie intensiv nutzen Sie diese? (Blackberry, iPhone, etc.)
Wie geschieht die Kommunikation, wenn die Teams über Standorte verteilt arbeiten?
Wie stellen Sie fest, ob ein(e) Kolleg(in) gerade verfügbar/anwesend / erreichbar ist
(„Presence Info“)? (Trial&Error, Statusinformationen, Outlook-Kalender)
Content/Dokumentation
Welche Inhalte, Dateien und Dateitypen benötigen Sie in diesem Prozess? (Auftragsformular, Dokument X, PDF)
Wo und wie werden diese Inhalte und Dateien abgelegt und verwaltet? (in Verzeichnissen
am Server, auf eigener Festplatte, im Intranet)
Gibt es einen Ort, wo Sie die benötigten Dateien zur gemeinsamen Nutzung speichern
können? (gemeinsame Dokumentenbibliotheken, Laufwerk)
Werden Inhalte/Daten in Papierform benötigt? Wenn Ja: Wie werden diese in den Prozess
eingebracht? (Scannen, Kopieren,…) Können Sie sich vorstellen die gesamten Inhalte
elektronisch abzubilden und abzulegen?
Anhänge
281
Welche Möglichkeiten zum Dokumentenaustausch haben Sie im Prozess? Welche nutzen
Sie? An wie vielen Personen senden Sie die Dokumente? (zentrale Datenhaltung, E-Mail,
Blogs, Wikis)
Welche Möglichkeiten zur Wissensdokumentation abseits der herkömmlichen Dokumentation und Kommunikation gibt es im Prozess? Welche nutzen Sie? (Wissensbibliotheken,
Blogs, Wikis)
In welcher Form erfolgt Ihre Arbeit in Teams? Werden Sie dabei softwaretechnisch unterstützt? (Projekt-/Teamräume, Aufgaben/Tasks, Kalender, Soziale Netzwerke, Whiteboard,
Posteingang mit Regeln, Excel-Listen)
Welche Art des Informations- und Datenaustausches zwischen Teams wird bevorzugt und
warum? (E-Mail, Telefon, Teamräume, Soziale Netzwerke, Blogs, Wikis, persönl. Kommunikation)
Wie komfortabel / einfach / zugänglich gestaltet sich die Suche nach benötigten Informationen im Prozess? (Personen-Suche im Intranet, Verfügbarkeit/Zugriffsbeschränkungen von
Informationen abteilungsübergreifend)
Prozessunterstützung / Workflow
Für welche Prozessschritte werden Formulare verwendet?
Liegen diese Formulare elektronisch oder in Papierform vor? Wenn digital, erfolgt die Weiterleitung elektronisch oder in Papierformat? (digitale Formulare, online ausfüllbar bzw. Papierformulare)
Wer kümmert sich um die Erstellung der Formulare und um die Verwaltung dieser? (Formularerstellung, Vorlagen, Dokumententypen, Templates)
Verwenden Sie Software-Unterstützung für den Workflow? Wenn Ja, welche?
Welche Phasen durchwandern die verwendeten Dokumente im Prozess? (Status: NeuAnlage, in Bearbeitung, wartet auf jemanden, Draft, Genehmigung, Ablage,…)
Wäre eine automatisierte, softwaremäßige Unterstützung des Prozesses sinnvoll?
Kreative neue Ideen (Innovation)
An welchen Schnittstellen (bzw. in welchen Arbeitsschritten) im Prozess entstehen kreative
neue Ideen? (in Bezug auf: Produktinnovationen, Prozessinnovationen, Geschäftsmodelle)
282
Anhänge
Was und wer (Rollen) sind die Treiber für kreative neuartige Ideen in diesem Prozess?
Technologische Unterstützung
Welche Endgeräte nutzen Sie im Prozess? (mobil, Laptop, Telefon)
Welche softwaretechnische Unterstützung erwarten Sie sich für diesen Prozess?
Schwachstellen im Ist-Prozess
Welche (technologische, organisatorische,…) Schwachstellen bestehen im derzeitigen IstProzess?
Verbesserungen an einen Soll-Prozess
Welche Verbesserungen können Sie sich für einen Soll-Prozess vorstellen?
Anhänge
283
Anhang E: Fragebogen zu Erfolgsfaktoren bei Teufelberger
Allgemeine Beurteilung der Themengebiete
1. Wie beurteilen Sie allgemein
a. die Dokumentation in Ihrem Unternehmen?
b. die Projektabwicklung in Ihrem Unternehmen?
c. die Kommunikation in Ihrem Unternehmen?
d. den Innovationsprozess in Ihrem Unternehmen?
2. Wie beurteilen Sie die softwaretechnische Unterstützung für Aktivitäten
a. zur Dokumentation in Ihrem Unternehmen? (z.B. Dokumentation von Projekten)
b. zur Projektabwicklung in Ihrem Unternehmen? (z.B. Meetings vorbereiten)
c. zur Kommunikation in Ihrem Unternehmen? (z.B. abteilungsübergreifende Kommunikation)
d. zur Innovation in Ihrem Unternehmen? (z.B. Diskussion / Bewertung kreativer neuer
Ideen)
3. Besteht Klarheit bezüglich Verantwortung und Zuständigkeiten auf allen Unternehmensebenen für
a. die Dokumentation?
b. die Projektabwicklung?
c. die Kommunikation?
d. Innovation?
4. Sind standardisierte und systematische Prozesse definiert für
d. Innovationen?
5. Werden Mitarbeiter ausreichend eingebunden in
a. in die Gestaltung der Dokumentation?
b. in die Gestaltung des Prozesses der Projektabwicklung?
c. in die Gestaltung des Prozesses für Kommunikation?
d. in die Gestaltung des Innovationsprozesses?
6. Wie beurteilen Sie die Verankerung von Innovationsmanagement-Aktivitäten in Ihrem
Unternehmen?
7. Sind Innovationsziele und –strategien bekannt?
8. Werden Mitarbeiter ausreichend durch Anreizsysteme (monetär, immateriell, teamorientiert) zum Wissensaustausch motiviert?
9. Sind ein regelmäßiges internes und externes Benchmarking und eine Wettbewerbsanalyse in ausreichendem Maße vorhanden?
Beurteilung der persönlichen Zielsetzung und individuellen Aufgabensituation
10. Gibt es ausreichend zeitliche Freiräume für
d. Innovationen?
284
Anhänge
11. Ist der Zugang zu neuem Wissen bzw. der Austausch von vorhandenem Wissen
hinreichend vorhanden und möglich?
12. Ist Bewusstsein, Verständnis und Motivation für das Vorantreiben von
a. Innovationen ausreichend vorhanden?
b. Wissensaustausch ausreichend vorhanden?
13. Ist die Bereitschaft für das Vorantreiben von
a. Innovationen ausreichend vorhanden?
b. Wissensaustausch ausreichend vorhanden?
14. Gibt es hinreichende Handlungs- und Verantwortungsspielräume für Mitarbeiter in
Ihrer Abteilung/Business Unit (Dezentralisierung des Innovationsmanagement)?
15. Sind die Tätigkeiten zum
a. Innovationsmanagement adäquat in die bestehenden Arbeitsprozesse/Abläufe integriert?
b. Wissensaustausch adäquat in die bestehenden Arbeitsprozesse/Abläufe integriert?
16. Wie beurteilen Sie Ihr Unternehmen im Hinblick auf eine geteilte Unternehmensvision,
gemeinsame Ziele, Werte und die Identifikation der Mitarbeiter mit dem Unternehmen?
17. Sind Motivation und Bereitschaft für Wissensbereitstellung durch schnelle, sichtbare
Erfolge und kontinuierliche Verbesserungen (KVP) ausreichend vorhanden?
18. Wird bei komplexen Aufgaben, Herausforderungen und Problemen durch direkte
Kommunikation, Wissensaustausch und gegenseitige Unterstützung eine gemeinschaftliche Lösung angestrebt (keine Abteilungsegoismen)?
19. Werden kreative neue Ideen (Innovationen) aus niedrigeren Hierarchiestufen ausreichend akzeptiert?
20. Ist die Möglichkeit Fehler zu begehen und daraus zu lernen gegeben (Fehlertoleranz)?
21. Ist eine wissens- und lernförderliche Unternehmenskultur, dh. die Bereitschaft
Wissen zu teilen und dem geteilten Wissen zu vertrauen („Vertrauenskultur“) ausreichend
vorhanden?
Anhänge
285
Anhang F: RACI-Matrix für das Vorgehensmodell
A1.1 Integrationsbedarf identifizieren
A1.2 [optional] Vorstudie durchführen
A1.3 Potentiale auf
unterschiedlichen
Integrationsebenen
vorstellen
A1.4 Projekt definieren
A2.1 Ist-Analyse
A2.2 Workshops
durchführen
A2.3 Erfolgsfaktorenanalyse durchführen
A 3.1: Anwendungsszenarien entwerfen
A 3.2: Feedback
einholen
A3.3 Design für Prototypentwicklung festlegen
A4.1 Prototyping
(„Perpetual Beta“)
A4.2 Schulung der
Beta-Benutzer
A4.3 Evaluierung
durchführen
A5.1 Abnahme
A5.2 Schulung Administratoren & Endbenutzer
A5.3 Kontinuierliche
Verbesserung
R
I
R
I
I
R
I
I
A
C
C
A
R
R
R
I
I
I
I
I
I
C
R
I
I
I
C
R
C
R
A
R
A
C
A
R
C
A
I
R
I
C
I
I
C
I
Administrator
Endbenutzer
Pilot-Partner
(Ext.) Umsetzungspartner
Beta-Benutzer
Kernteam
(Top-) Management
(Ext.) Koordinator
Rolle /
Aktivität (A)
Projektleiter
Tabelle 29: Zuordnung von Rollen zu Aktivitäten (RACI-Matrix)
I
C
C
I
I
R
I
C
I
C
C
C
C
R
I
C
C
R
C
R
C
I
I
I
R
R
I
I
C
C
C
I
I
I
I
I
I
R: Verantwortlich („Responsible“), A: Rechenschaftspflichtig („Accountable“), C: Beratend („Consulted“), I:
Informiert („Informed“)
286
Anhänge
Abkürzungsverzeichnis
B2B
Business-to-Business
B-to-B
Business-to-Business
BEEP
Blocks Extensible Exchange Protocol
BI
Business Intelligence
BNM
Business Network Model
BPO
Business Process Outsourcing
DIBPM
Dynamic Inter-Organizational Business Process Management
CSCW
Computer Supported Cooperative Work
CSV
Comma Separated Value
CO2
Kohlendioxid
DBMS
Datenbankmanagementsystem
DoI
Diffusion of Innovation
DSL
Digital Subscriber Line
DSS
Decision Support System
EAI
Enterprise Application Integration
EDI
Electronic Data Interchange
EMS
Environmental Management System
ERP
Enterprise Resource Planning (System)
ESB
Enterprise Service Bus
F&E
Forschung und Entwicklung
GPRS
General Packet Radio Service
IaaS
Infrastructure-as-a-Service
IKT
Informations- und Kommunikationstechnologie
Anhänge
IOS
287
Interoperabilitätsstandards,
Interorganisationale Informationssysteme (Englisch: Inter-organizational
systems)
IS
Informationssystem
ISO
International Organization for Standardization
ISDN
Integrated Services Digital Network
ISM
Intelligent Supplier Management
IT
Informationstechnik
ITO
Information Technology Outsourcing
KMU
Kleines und mittleres Unternehmen
LDAP
Lightweight Directory Access Protocol
OSI
Open Systems Interconnection
P2P
Peer to Peer
PaaS
Platform-as-a-Service
PDA
Personal Digital Assistant
PDF
Portable Document Format
RFC
Request for Comments
RFID
Radio Frequency Identification
RPC
Remote Procedure Call
SaaS
Software-as-a-Service
SOA
Service Orientierte Architektur
SOAP
Simple Object Access Protocol
TAM
Technology Acceptance Model
TAN
Transaktionsnummer
TCP/IP
Transmission Control Protocol / Internet Protocol
288
Anhänge
TCT
Transaction Cost Theory
TKT
Transaktionskostentheorie
TOE
Technology-Organization-Environment
UMTS
Universal Mobile Telecommunication System
URL
Uniform Resource Locator
USB
Universal Serial Bus
VAN
Value-Added Netzwerk
WFMS
Workflowmanagement System
WSDL
Web Services Description Language
WSFL
Web Services Flow Language
WSMF
Web Service Modeling Framework
WS-BPEL Web Services Business Process Execution Language
WWS
Warenwirtschafts-System
XML
extensible Markup Language
ZLE
Zero Latency Enterprise
Anhänge
289
Lebenslauf
Persönliche Angaben
Name:
Dietmar Nedbal
Position:
Wissenschaftlicher Mitarbeiter
Forschungsschwerpunkt Digital Business
Kontakt:
FH OÖ Forschungs & Entwicklungs GmbH
Wehrgrabengasse 1-3
A-4400 Steyr
+43 7252 884 33415
dietmar.nedbal@fh-steyr.at
Ausbildung
2008 – 2013:
Doktoratsstudium der Sozial- und Wirtschaftswissenschaften, Johannes
Kepler Universität Linz
1995 – 2000:
Studium Wirtschaftsinformatik (Mag.), Johannes Kepler Universität Linz
1990 – 1995:
Bundeshandelsakademie, Steyr
Berufliche Stationen
Seit Okt. 2007:
Wissenschaftlicher Mitarbeiter am Forschungsschwerpunkt „Digital
Business“, Forschungsinteressen: betriebliche Integration und Integrationslösungen, Web 2.0 und Enterprise 2.0, Green IS, Cloud Computing
2001 – 2007:
Nebenbeschäftigung als externer Lektor (NBL) an der FH-Steyr, Fachbereich Informatik/Informationstechnologie
2000 – 2007:
Software-Entwickler bei RiS GmbH in Steyr, ab 2003: Leiter der Softwareentwicklung, Apr. 2004: Erteilung der Prokura.
1999 – 2000:
Programmierer bei Lesezone.at und Lion.cc in den Bereichen
E-Business, Warenwirtschaft und Logistik
290
Anhänge
Projekte
Zeitraum:
Unternehmen:
Typ:
Projekt:
2012 - 2014
FH OÖ
F&E Projekt (Land OÖ - Regio 13)
OptiCloud - Interdisziplinäre Betrachtung und Gestaltung von optimalen
"Private Clouds"
Zeitraum:
Unternehmen:
Typ:
Projekt:
2011 - 2012
FH OÖ
Industrieprojekt
Fronius GmbH: Enterprise 2.0 bei Fronius - Innovationsnetzwerke
Zeitraum:
Unternehmen:
Typ:
Projekt:
2010 - 2013
FH OÖ
F&E Projekt (Land OÖ - Regio 13)
4EMOBILITY - Energy-efficient Economic and Ecological Mobility
Zeitraum:
Unternehmen:
Typ:
Projekt:
2010 - 2011
FH OÖ
Industrieprojekte
Integrationslösungen bei Teufelberger GmbH und NKE GmbH
Zeitraum:
Unternehmen:
2009 - 2012
FH OÖ
Typ:
Projekt:
F&E Projekt (FFG COIN „Aufbau“)
SCIM 2.0: Effektives Supply Chain Information Management in Wertschöpfungsnetzwerken mittels Enterprise 2.0
Zeitraum:
Unternehmen:
Typ:
Projekt:
2007 - 2009
FH OÖ
F&E Projekt (FH OÖ basisfinanziert)
GuideBIS: Guidance Model for Business Integration Solutions
Zeitraum:
Unternehmen:
Typ:
Projekt:
2006 - 2007
RiS GmbH
F&E Projekt (FFG Basisprogramm)
RiS-Kommunal 3.0: Entwicklung eines barrierefreien e-GovernmentSystems für Gemeinden
Anhänge
291
Zeitraum:
Unternehmen:
Typ:
Projekt:
2005
RiS GmbH
Industrieprojekt
Kommunalnet.at: Intranet-Plattform für Gemeindebedienstete
Zeitraum:
Unternehmen:
Typ:
Projekt:
2002 - 2004
RiS GmbH
F&E Projekt (EU – FP5 IST)
CIPHER - Communities of Interest Promoting Heritage of the European
Regions
Zeitraum:
2001 - 2003
Unternehmen:
Typ:
Projekt:
RiS GmbH
F&E Projekt (Land OÖ – Ziel-2)
Regionales E-Commerce-System
Zeitraum:
Unternehmen:
Typ:
Projekt:
2001 - 2002
RiS GmbH
F&E Projekt (Land OÖ – Ziel-2)
Die virtuelle Region: Implementierung von virtuellen Regions- und
Kommunikationsportalen.
Zeitraum:
Unternehmen:
Typ:
Projekt:
2000 - 2001
RiS GmbH
Industrieprojekt
RiS-Kommunal 2.0 – Erstellung eines mehrsprachigen Content Management Systems für Gemeinden.
Publikationstätigkeit
2013
#1 D. Nedbal - A Process Model to guide the Integration of Business Processes and Services within
and across Organizations - International Journal of Services, Economics and Management, Vol. 5, No.
1, 2013, pp. 154-177
#2 D. Nedbal, A. Auinger, P. Brandtner - Standortübergreifende kooperative Innovationsnetzwerke:
Wissenschaftliche Methodik und Umsetzung in der Praxis - Tagungsband des 7. Forschungsforums
der Österreichischen Fachhochschulen, Dornbirn, Österreich, 2013
2012
#1 D. Nedbal, A. Auinger, A. Hochmeier, A. Holzinger - A Systematic Success Factor Analysis in the
Context of Enterprise 2.0: Results of an Exploratory Analysis comprising Digital Immigrants and Digital
Natives - Proceedings of the 13th International Conference on Electronic Commerce and Web Technologies (EC-Web 2012), Vienna, Österreich, 2012, pp. 163-175
#2 D. Nedbal - An Examination of the Economic Value and Contribution to Energy Efficiency of SaaS
Solutions: The Case of E-Invoicing - 2012 IEEE First International Conference on Services Economics
(SE 2012), Honolulu, Vereinigte Staaten von Amerika, 2012, pp. 1-8
292
Anhänge
#3 D. Nedbal, A. Auinger, W. Wöß - Business-to-Business-Integration in Wertschöpfungsnetzwerken HMD - Praxis der Wirtschaftsinformatik, Vol. 49, No. 285, 2012, pp. 63-72
#4 D. Nedbal, W. Wetzlinger - Technical Complexity as Important Factor for Green IS Solutions:
Theoretical Background and Exploratory Study - Conf-IRM 2012 Proceedings, Wien, Österreich, 2012,
pp. 1-11
#5 D. Nedbal, W. Wetzlinger, T. Kern - Handlungsfelder und Lösungsansätze im Kontext von "Green
IS": Eine explorative Studie - Proceedings FFH 2012, Graz, Österreich, 2012, pp. 95-99
#6 A. Auinger, D. Nedbal, H. Kirchberger - Einführung des "Intranet T2.0" bei der Teufelberger GmbH
in Web 2.0 in der Unternehmenspraxis: Social-Media-Grundlagen und -Trends sowie Methoden und
Fallstudien zu Enterprise 2.0 (Contributions to Book: Part/Chapter/Section 8), (Editors: A. Back, N.
Gronau, K. Tochtermann) - Oldenburg Wissenschaftsverlag, 2012, pp. 387-399
#7 A. Auinger, D. Nedbal, H. Kirchberger, P. Brandtner - Teufelberger Intranet T2.0: Einführung und
Umsetzung - Technical Report, Teufelberger GmbH, Österreich, 2012, pp. 49
2011
#1 D. Nedbal - Guiding B2B Integration of Business Processes and Services: A Process Model for
SMEs - Proceedings of the 2nd International Conference on on Emerging Intelligent Data and Web
Technologies (EIDWT-2011), Tirana, Albanien, 2011, pp. 114-119
#2 D. Nedbal, W. Wetzlinger, A. Auinger, G. Wagner - Sustainable IS Initialization Through Outsourcing: A Theory-Based Approach - Proceedings of the 17th Americas Conference on Information
Systems (AMCIS 2011 Proceedings), Detroit, Vereinigte Staaten von Amerika, 2011, pp. 1-10
#3 A. Auinger, D. Nedbal, A. Hochmeier, A. Holzinger - User-Centric Usability Evaluation For Enterprise 2.0 Platforms: A complementary multi-method approach - Proceedings of the International
Conference on e- Business (ICE-B 2011), Sevilla, Spanien, 2011, pp. 119-124
#4 A. Auinger, A. Hochmeier, D. Nedbal - Organization-driven Approach for Enterprise 2.0 Projects Proceedings of the fifth Research Forum of the Austrian University of Applied Sciences, Wien (Favoriten), Österreich, 2011, pp. 136-139
#5 A. Auinger, A. Hochmeier, D. Nedbal - Cross-Organizational Enterprise 2.0 Projects as a Door
Opener for Open Ecosystems - Proceedings of the International InCo Conference 2011, Ljubljana,
Slowenien, 2011
#6 A. Auinger, A. Hochmeier, D. Nedbal - An Approach For Implementing Enterprise 2.0 Platforms:
Methodology And Selected Results Of Pilot Projects - Proceedings of the IADIS International Conference on Information Systems 2011 (IS 2011), Avila, Spanien, 2011, pp. 179-185
2010
#1 A. Auinger, D. Nedbal, A. Holzinger, M. Ebner, N. Scerbakov - MashUps for e-Learning 2.0 – IEEE
Proceedings of the International Conference on Management Science and Information Engineering
(ICMSIE 2010), Zhengzhou, China, 2010
#2 D. Nedbal, G. Petz - Implementation Concept for an Accessible Web CMS - Computers Helping
People with Special Needs; Springer Lecture Notes in Computer Science (LNCS), Wien, Österreich,
2010, pp. 456-463
#3 A. Auinger, M. Lechner, D. Nedbal - Supply Chain Information Management mittels Enterprise 2.0:
Analyse und Software-Architektur - Tagungsband des 4. Forschungsforum der österreichischen
Fachhochschulen, Pinkafeld, Österreich, 2010, pp. 91-97
#4 D. Nedbal, A. Auinger - Effektives Supply Chain Information Management in Wertschöpfungsnetzwerken mittels Enterprise 2.0 in Forschungsbeiträge zur Logistik (Editors: F. Staberhofer, C. Engelhardt-Nowitzki) - Shaker Verlag, 2010, pp. 169-180
#5 D. Nedbal, A. Auinger - Framework zur Steigerung der Energieeffizienz durch unternehmensübergreifende B2B Integrationen in Energieeffiziente Mobilität - Shaker Verlag, 2010, pp. 92-104
2009
#1 A. Auinger, H. Konnerth, D. Nedbal, W. Wetzlinger - Enterprise Mashups for Collaborative ELearning Environments - Proceedings of Interactive Computer-Aided Learning 2009, Villach, Österreich, 2009, pp. 1063-1068
#2 A. Auinger, D. Nedbal, M. Ebner, A. Holzinger - Mixing Content and Endless Collaboration MashUps: Towards Future Personal Learning Environments - Proceedings of HCI International 2009;
Anhänge
293
Springer Lecture Notes in Computer Science, San Diego, Vereinigte Staaten von Amerika, 2009, pp.
14-23
#3 A. Auinger, D. Nedbal, W. Wöß - A Holistic Approach for B2B Integration at Different Conceptual
Levels - Proceedings of the 2009 International Conference on e-Learning, e-Business, Enterprise
Information Systems, and e-Government (EEE'09), Las Vegas, Vereinigte Staaten von Amerika, 2009,
pp. 179-185
#4 A. Auinger, D. Nedbal - Effective Supply Chain Information Management in Supply Networks using
Enterprise 2.0 - Proceedings of the 2009 International Conference on e-Learning, e-Business, Enterprise Information Systems, and e-Government (EEE'09), Las Vegas, Vereinigte Staaten von Amerika,
2009, pp. 213-217
2008
#1 A. Auinger, H. Konnerth, D. Nedbal - Potential of Web-Mashups for Marketing 2.0 - Proceedings
FH Science Day 2008, Linz, Österreich, 2008, pp. 436-445
#2 W. Wetzlinger, G. Wagner, D. Nedbal - Supply Chain Interaction by Using SCA for B2B and B2G
Information Systems - Proceedings FH Science Day 2008, Linz, Österreich, 2008, pp. 475-482
#3 D. Nedbal, G. Petz - A Software Solution for Accessible E-Government Portals - Computers
Helping People with Special Needs, Linz, Österreich, 2008, pp. 338-345
#4 A. Auinger, D. Nedbal - Towards a Guidance Model for Business Integration Solutions - Proceedings of the International Joint Conference on e-Commerce, e-Administration, e-Society and eEducation, Bangkok, Thailand, 2008, pp. 15
2007
#1 A. Auinger, D. Nedbal - GuideBIS - Guidance Model for Business Integration Solutions - Proceedings of the IADIS International Conference on e-Commerce 2007 (EC2007), Algarve, Portugal, 2007,
pp. 271-275

Entwicklung_eines_Vorgehensmodells_Nedbal_2013

Transcription

Similar documents

Dokument 3 - OPUS - Leuphana Universität Lüneburg

Dokument_1.

Folien - E-Finance Lab Frankfurt am Main

Effektives Kunden management im Retail Banking

Einladung-PBS-aktiv2014 - PBS Austria