Komplexität von Informationssystem-Entwicklungsprojekten

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung

2 Grundlagen
2.1 Informationssysteme
2.1.1 Grundlagen zu Informationssystemen
2.1.2 Systemtheorie
2.2 Informationssystem-Entwicklungsprojekte
2.2.1 Informationssystem-Entwicklungsprojekte – Ablauf und Management
2.2.2 Vorgehensmodelle
2.2.3 Anschaffungsprozess von Standardsoftware
2.3 Komplexität
2.3.1 Allgemeine Definitionen und Konzepte von Komplexität
2.3.2 Komplexitätstheorie und Komplexitätsforschung
2.3.3 Komplexität im Rahmen eines ISDP
2.3.4 Rahmenwerk von Xia&Lee
2.4 Gang der Untersuchung

3 Ursachen und Wirkungen von Komplexität in ISDP
3.1 Strukturelle organisatorische Komplexität
3.1.1 Einsatz von bereichsübergreifenden Projektteams
3.1.2 Einbindung verschiedenen Hersteller und Anbieter
3.1.3 Koordination mehrerer Abteilungen
3.2 Strukturelle technische Komplexität
3.2.1 Echtzeitdatenverarbeitung
3.2.2 Mehrere Softwareumgebungen
3.2.3 Mehrere Technologieplattformen
3.2.4 Integration mit anderen Systemen
3.3 Dynamische organisatorische Komplexität
3.3.1 Rapider Wandel der Organisationsstruktur
3.3.2 Rapider Wandel der Geschäftsprozesse und Betriebsabläufe
3.3.3 IS-bedingter Wandel der Geschäftsprozesse
3.3.4 IS-bedingter Wandel der Organisationsstruktur
3.3.5 Rapider Wandel des Informationsbedarfes
3.4 Dynamische technische Komplexität
3.4.1 Rapider Wandel der IT-Architektur
3.4.2 Rapider Wandel der IT-Infrastruktur
3.4.3 Rapider Wandel der Entwicklungssoftware

4 Messbarkeit und Beherrschungsmöglichkeiten von Komplexität
4.1 Messbarkeit von Komplexität
4.2 Strategien, Maßnahmen und Konzepte zur Beherrschung von Komplexität
4.2.1 Individuelle Beherrschungsmaßnahmen
4.2.2 Strategien und Maßnahmen zur Komplexitätsbeherrschung

5 ISDP und komplexe (adaptive) Systeme
5.1 Komplexe Systeme
5.2 Komplexitätsprinzipien der Informationssystem-Entwicklung
5.3 Reaktion von Organisationen auf Komplexität

6 Zusammenfassung und kritische Würdigung

Literaturverzeichnis

Anhang

A Rahmenbedingungen der Projektabwicklung nach Jenny

B Restriktionen der Projektabwicklung nach Jenny

C Leitfaden zu den Experteninterviews

D Komplexitätsmaße

Abbildungsverzeichnis

Abbildung 2.1: Systematischer Aufbau der Bereiche und Beziehungen eines IS

Abbildung 2.2: Schalenmodell des Informationssystems

Abbildung 2.3: Systematisierung der Informations- und Kommunikationstechnik

Abbildung 2.4: Pfade der IS-Einführung

Abbildung 2.5: Projektabwicklungszyklus

Abbildung 2.6: Wasserfallmodell

Abbildung 2.7: Spiralmodell

Abbildung 2.8: Rational Unified Process

Abbildung 2.9: Beschaffungszyklus für Standardsoftware

Abbildung 2.10: Verhältnis von Komplexität zu Unordnung

Abbildung 2.11: Rahmenwerk für die Komplexität von Informationssystem-Entwicklungsprojekten

Abbildung 3.1: Systemmodel des Business Process Change

Abbildung 3.2: Architechtural drift

Abbildung 3.3: Wirkungspfade des infrastrukturellen Drifts

Abbildung 3.4: Infrastructure Skill Gap

Abbildung 5.1: Schematische Darstellung eines komplexen Systems

Abbildung 5.2: Schematische Darstellung eines komplexen adaptiven Systems

Tabellenverzeichnis

Tabelle 2.1: Komplexitätsmaße

Tabelle 3.1: Anpassungsoptionen für ERP-Systeme

Tabelle 3.2: Kostenprofile der Organisationsformen

Tabelle 3.3: Indikatoren der IT-Infrastruktur

Tabelle 4.1 Zusammenfassung der Messgrößen

Tabelle 4.2: Zusammenfassung der Messgrößen der Interviews

Tabelle 4.3: Zusammenfassung der Messgrößen aus den Interviews

Tabelle 4.4: Einordnung der Maßnahmen zur Reduktion systembedrohlicher Überkomplexität

Tabelle 4.5: Maßnahmen zur Reduktion systembedrohlicher Überkomplexität

Tabelle 4.6: Einordnung der Maßnahmen zur Reduktion ineffizienter Überkomplexität

Tabelle 4.7: Maßnahmen zur Reduktion ineffizienter Überkomplexität

Tabelle 4.8: Einordnung der Maßnahmen zur Reduktion ineffektiver Überkomplexität

Tabelle 4.9: Maßnahmen zur Reduktion ineffektiver Überkomplexität

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Als im Juli 1997 die Firma W. L. Gore & Associates, Hersteller des Stoffes Gore-Tex, feststellte, dass ihr Abrechnungssystem der Firma PeopleSoft Inc. Gehaltsschecks für Donald Duck, Mickey Mouse und deren Zeichentrickkameraden ausstellte, sorgte dies nicht für Erheiterung, sondern für ernsthafte Verwirrung in der Personalabteilung.^[1] Die zu Testzwecken angelegten fiktiven Angestellten konnten nach der Testphase nicht mehr aus dem System entfernt werden.^[2] Der Vorfall zog einen Rechtsstreit mit der Beratungsfirma Deloitte & Touche nach sich, in der Gore & Associates $ 2,8 Millionen zugesprochen wurden.^[3] Deutlich härter traf es die Firma FoxMeyer Corp., die eine Drogeriemarkt-Kette in Nordamerika betrieb und durch die fehlerhafte Einführung eines neuen SAP R/3 Systems in die Insolvenz getrieben wurde.^[4] Die Kosten für das System beliefen sich auf mehr als $65 Millionen und die Entwicklung dauerte mehr als drei Jahre (1993-1996).^[5] Auch diese fehlgeschlagene Einführung zog einen Rechtsstreit nach sich, in welchem FoxMeyer $500 Millionen jeweils von SAP, Andersen Consulting und Deloitte & Touche für die fehlgeschlagenen Implementierung forderte.^[6] Mit diesen Problemen sind die beiden Firmen nicht allein. In der Europäischen Union wurden im Jahre 2004 €142 Milliarden für fehlgeschlagenen Informationssystemprojekte abgeschrieben.^[7] Die Konsequenzen fehlerhafter Informationssystem-Entwicklung beschränken sich jedoch nicht nur auf wirtschaftliche Schäden, sondern haben in der Vergangenheit auch Menschenleben gefordert, wie das Beispiel des London Ambulance Service zeigt.^[8] Dort fiel am 27. Oktober 1992 das computergestützte Befehls- und Kontrollsystem der Einsatzleitstelle aus, so dass viele Rettungswagen entweder verspätet oder gar nicht an den Unfallstellen eintrafen.^[9] Die Zahl der dadurch verursachten Todesfälle kann nur geschätzt werden.^[10]

Noch immer sind viele solcher Projekte nicht in der Lage die angestrebten Projektziele in der vorgesehenen Zeit und zu den vorgesehenen Kosten zu verwirklichen.^[11] Etwa ein Drittel aller Softwareprojekte scheitert, ein weiteres Drittel wird mit Zeitverzug und Budgetüberschreitungen fertig gestellt und nur ein Drittel der Projekte wird in der vorgesehenen Zeit und im Rahmen des bewilligten Budgets abgeschlossen.^[12] Die Gründe dafür sind vielschichtig. Viele bekannte Probleme der Softwareentwicklung gehen auf die der Software inhärenten Komplexität zurück.^[13] Diese Komplexität führt nicht nur zu Verzögerungen und Budgetüberschreitungen, sondern auch zu Management- und Technikproblemen.^[14] Jedoch birgt nicht nur die zu entwickelnde Software, sondern auch die spezielle Projektform einer Informationssystem-Entwicklung eine immense Komplexität in sich, da im Rahmen eines solchen Projektes nicht nur technische, sondern auch organisatorische Themen in Einklang gebracht werden müssen.^[15] Komplexität bzw. ihre Auswirkungen und Konsequenzen gehören damit zu den wichtigsten Gründen, warum Informationssystem-Entwicklungsprojekte scheitern. Die oben erwähnten Probleme in den Bereichen Technik und Management werden durch das Entstehen von immer größeren Systemen verstärkt, da sie Komplexität in bisher nicht bekanntem Ausmaße aufweisen, so dass heutige Entwicklungsmethoden auf dem Gebiet der Softwareentwicklung nicht mehr auf diese Projekte anwendbar sind.^[16] Dies manifestiert sich in den Fehlschlagsraten von Informationssystem-Entwicklungsprojekten, so dass einer Studie zu Folge zwei Drittel aller komplexen Projekte abgebrochen werden und ein Drittel mit Budgetüberschreitungen zu kämpfen hat.^[17]

Die genannten Gründe motivieren damit nicht nur ein hinreichend wirtschaftliches, sondern auch akademisches Interesse der Komplexität von Informationssystem-Entwicklungsprojekten nachzugehen und neue Lösungsansätze zu erforschen. Damit jedoch ein effektives Management solcher Projekte entstehen kann, ist Grundlagenforschung auf dem Gebiet der Komplexität unerlässlich.^[18] Da Komplexität nicht nur auf den Gebieten des Projektmanagements und der Informationssysteme, sondern auch im Bereich der Sozialwissenschaften und vielen anderen Gebieten, wie Physik, Biologie und Informatik, an Bedeutung zugenommen hat, wird die Forschung am Phänomen Komplexität zu einer interdisziplinären Angelegenheit.^[19]

Diese interdisziplinären Sichten auf Komplexität spiegeln sich auch bei der Betrachtung von Komplexität im Rahmen von Informationssystem-Entwicklungsprojekten wieder, so dass sich die nachfolgende Untersuchung nicht nur auf die Erkenntnisse der Wirtschaftsinformatik und/oder der Wirtschaftswissenschaften stützt.^[20] Ziel der vorliegenden Untersuchung ist es daher Ursachen, Wirkungsweisen, Meßmethoden und Reduktionsmöglichkeiten für die Komplexität von Informationssystem-Entwicklungsprojekten in der Literatur und in eigens für die Untersuchung durchgeführten Experteninterviews zu finden. Dabei werden in Kapitel 2 Grundlagen zu Informationssystemen, Informationssystem-Entwicklungsprojekten und der wissenschaftlichen Sichtweise von Komplexität gelegt, welche am Ende des Kapitels zu einem Untersuchungsschema verdichtet werden. Anhand dieses Untersuchungsschemas werden in Kapitel 3 Ursachen und Wirkungsweisen aus der Literatur und den Experteninterviews vorgestellt, welche das vielschichtige Beziehungsgeflecht eines Informationssystem-Entwicklungsprojektes beleuchten sollen. Diese Ursachen und Wirkungsweisen bilden den Grundstein für Kapitel 4 in welchem Messmethoden und Reduktionsmöglichkeiten für die in Kapitel 3 vorgestellten Komplexitäten vorgeschlagen werden sollen. Die Untersuchung schließt mit einer kurzen Darstellung eines neueren, ganzheitlicheren Betrachtungsansatzes der Informationssystem-Entwicklung und einer kritischen Würdigung der erarbeiteten Resultate.

2 Grundlagen

Im folgenden Kapitel wird der Leser mit den Thematiken Informationssysteme, Informationssystem-Entwicklungsprojekte und Komplexität vertraut gemacht. Dabei wird zuerst auf Definitionen und Theorien zu Informationssystemen eingegangen. Anschließend werden Projekte beleuchtet, welche den Aufbau und die Installation eines solchen Systems zum Ziel haben. Nachdem der Leser ein Verständnis von Informationssystemen und deren Entwicklung bekommen hat, werden Grundzüge der heutigen Komplexitätsauffassungen und assoziierter Konzepte vorgestellt. Im Rahmen dieser Vorstellung werden auch Beiträge behandelt, die eine Brücke zwischen den Themen Komplexität und Informationssystem-Entwicklungsprojekten schlagen. Das Kapitel schließt mit einem Untersuchungsschema, welches die Komplexität von Informationssystem-Entwicklungsprojekten systematisch beleuchtet.

2.1 Informationssysteme

Im ersten Grundlagenteil werden Definitionen und Theorien zu Informationssystemen allgemein vorgestellt. Hierbei wird nicht auf die Abgrenzung einzelner Auffassungen aus der Theorie eingegangen, sondern vielmehr versucht einen allgemeinen, für die Untersuchung notwendigen Überblick aus der Perspektive der aktuell vorherrschenden Literatur über die Thematik der Informationssysteme zu geben. Aus der enormen Fülle der verschiedenen Theorien wird nur eine Theorie, die Systemtheorie, vorgestellt, welche auch für das Verständnis der weiteren Untersuchungsschritte notwendig ist. Im Zusammenhang mit der Systemtheorie werden zwei weitere systemtheoretische Ansätze, der sozio-technische Ansatz und der sprachkritische Ansatz, vorgestellt, die dem Leser einen Einblick in die systemtheoretische Untersuchung von Informationssystemen geben und zur Orientierung der weiteren Untersuchungen dienen.

2.1.1 Grundlagen zu Informationssystemen

Informationssysteme (IS) sind Systeme, die der Information und Kommunikation dienen^[21]. Sie bestehen aus Menschen und Maschinen.^[22] Menschen und Maschinen werden im Rahmen der betrieblichen Aufgabenstellung durch das IS organisatorisch in Beziehung gesetzt. Deshalb werden IS auch als „Mensch-Aufgabe-Technik-Systeme“ bezeichnet.^[23] Somit stellen der Mensch, die betriebliche Aufgabenstellung und die Informationstechnik die Hauptkomponenten dieser Systeme dar.^[24]

Informationssysteme sind aufgrund ihres Zweckes, tief in das betriebliche und organisatorische Wirkungsgefüge eines Unternehmens eingebettet. Eine Möglichkeit das Zusammenspiel der betrieblichen Einheiten und Komponenten mit dem IS zu gliedern und systematisch darzustellen, stellt das Rahmenwerk von Bacon; Fitzgerald (2001) in Abbildung 2.1 dar.^[25] Es umfasst 5 Bereiche und 8 Beziehungen zwischen diesen Bereichen. Der erste Kernbereich „IS Development, Acquisition & Support“ umfasst die wichtigsten Themen bei der Entwicklung und Einführung eines IS. Diese Themenbereiche stellen unter anderem den Kern eines Informationssystem-Entwicklungsprojektes (ISDP) dar. Ursprünglich war die IS Entwicklung („Systems Development“) in Form der Systemanalyse („system analysis“) der Kern des Bereiches.^[26] Da jedoch heutzutage deutlich mehr IS als vorgefertigte Lösungen in Form von Standardsoftware gekauft werden, hat sich der Schwerpunkt im Unternehmen auf die Anschaffung bzw. den Kauf von „vorgefertigten“ IS-Lösungen verlagert.^[27] Die Verlagerung hat auch andere Tätigkeitsbereiche im Unternehmen deutlich aufgewertet. So machen heute Wartung, Schulung und Help Desk deutlich mehr an IS/IT-Aufwand aus, als früher die Entwicklung des IS, die heutzutage eher außerhalb des Unternehmens stattfindet. Die Fokussierung der IS auf die Menschen im Unternehmen und deren Informationsbedürfnisse war schon immer ein zentraler Punkt in der Gestaltung von IS und befindet sich im Kernbereich „People & Organization“.^[28] Die IT („Information and Communications Technology“) stellt einen Kernbereich dar, da sie erst die Voraussetzungen des Informationsaustausches möglich macht. Der letzte Kernbereich „Operations & Network Management“ geht erst durch die Schaffung des IS hervor und sorgt für den reibungslosen Ablauf des bestehenden IS. Der zentrale Kernbereich des Rahmenwerkes bildet der Bereich „Information for Knowledge Work, Customer Satisfaction & Business Performance“. Da sich herausgestellt hat, dass der primäre Zweck der reinen Bereitstellung von Informationen zur Entscheidungsfindung und –unterstützung eine zu enge Auffassung darstellt, werden auch andere Komponenten und Felder integriert.^[29]

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Bacon; Fitzgerald (2001), S.53

Abbildung 2.1: Systematischer Aufbau der Bereiche und Beziehungen eines IS

Deshalb gehören neben übersichtlichen Benutzeroberflächen und Datenqualität auch das Wissensmanagement und das Lernen der Organisation, welches immer wichtiger wird, um im Wettbewerb bestehen zu können.^[30]

Eine weitere systematische Möglichkeit ist die Betrachtung der unterschiedlichen Aufgaben und Funktionen, die IS im Unternehmen wahrnehmen können. Dabei kann man IS anhand ihrer Einsatzbereiche und Funktionen in den verschiedenen Unternehmensbereichen unterscheiden. Für jeden Unternehmensbereich finden sich IS auf operativer, taktischer und strategischer Ebene.^[31] Auf der operativen Ebene werden sog. Transaktionssysteme (Transaction Processing System, TPS) eingesetzt, welche die täglichen Routinearbeiten eines Unternehmens erledigen. Auf der taktischen Ebene kann man zwei verschieden IS-Typen ausmachen, die dem Management zur Verfügung stehen. Zum einen das Management-Information-System (MIS) und zum anderen das Entscheidungsunterstützungssystem (Decision Support System, DSS). Ein MIS stellt den Entscheidungsträgern Berichte und aktuelle Unternehmenszahlen zur Verfügung und unterstützt somit das Management bei Planung, Kontrolle und dem Treffen von Entscheidungen. DSS basieren auf einer Reihe von Datenanalysemodellen und helfen Entscheidungsträgern und Führungskräften beim Treffen von nicht alltäglichen und sehr unstrukturierten Entscheidungen. Ein DSS greift dabei typischerweise auf interne Systeme wie TPS und MIS zu und besitzt zugleich auch Zugang zu externen Informationsressourcen, um den Führungskräften beim Entscheiden die aktuellsten und bestmöglichsten Informationen zur Verfügung zu stellen. Auf der strategischen Ebene befinden sich die Führungsunterstützungssysteme (Executive Support System, ESS), die das obere Management bei der Entscheidungsfindung unterstützen. ESS sind weniger analytisch ausgerichtet wie DSS und beziehen ihre Informationen aus externen und internen Systemen. Funktional gesehen lassen sich auf den einzelnen Management-Ebenen in jedem Unternehmensbereich wieder verschiedenen Systemtypen auffinden, wie z.B. ein Buchhaltungssystem im Bereich Rechnungswesen. Auf eine gesonderte Darstellung der bereichsspezifischen Systeme soll hier verzichtet werden. Der geneigte Leser sei auf die einschlägige Literatur verwiesen.^[32]

Im täglichen Unternehmensgeschehen findet ein reger Datenaustausch zwischen den Abteilungen und somit zwischen den verschiedenen Systemen statt.^[33] Um allen Abteilungen der Zugriff auf die notwendigen Daten im Unternehmen zu ermöglichen, kann auf unternehmensweite Softwarelösungen (Enterprise Resource Planning, ERP) zurückgegriffen werden. Beispiele dafür sind z.B. die Produkte von SAP oder Oracle. Diese Softwarelösungen automatisieren eine Reihe von Prozessen in den unterschiedlichsten Unternehmensbereichen und sorgen für eine einheitliche Datenbasis, die meist über eine zentrale Datenbank realisiert wird.

2.1.2 Systemtheorie

Um die oben vorgestellten Beziehungen, Funktionen, Aufgaben und Arten eines IS zu untersuchen, hat die Literatur eine Vielzahl an Theorien hervorgebracht, deren Darstellung den Rahmen dieser Arbeit sprengen würde. Aus dieser Vielzahl an Theorien und Ansätzen wird im folgenden nur die Systemtheorie vorgestellt, da sie für den weiteren Gang der Untersuchung als Orientierung unerlässlich ist.

Das Wort „System“ entstammt der griechischen Sprache und bezeichnet das Zusammenwirken von verschiedenen Teilen zu einem Ganzen.^[34] Dabei war schon aus der Antike bekannt, dass Systeme nicht nur gegenständlich, sondern auch gedanklich existieren können. Im Gegensatz zu den gedanklichen oder symbolischen Systemen bezeichnet man Systeme, die tatsächlich existieren als Realsysteme, die sich ihrerseits wieder in natürliche und vom Menschen geschaffene Systeme unterteilten. Die Systemtheorie beschäftigt sich mit Realsystemen in verschiedensten Wirklichkeitsbereichen. Im organisatorischen Kontext beschreibt ein System eine gegenüber der Umwelt abgegrenzte Menge an Elementen zwischen denen Beziehungen bestehen.^[35] In diesem Kontext werden Systeme in Beziehungen, Elemente und Dimensionen zerlegt. Die gegenseitigen Einwirkungen von Elementen werden abstrakt als Information bezeichnet. Veränderungen eines Elementes beeinflussen auch immer die anderen Elemente. Die einzige unabhängige Größe eines Systems stellt die Zeit dar.

Bei der Analyse solcher Systeme ist Systemdenken gefragt. Systemdenken erfordert die Vergegenwärtigung der grundlegenden Mechanismen und Methoden des betrachteten Systems.^[36] Die Analyse erfolgt dann mittels geeigneter Methoden, indem z.B. vom Groben ins Detail (top-down) gegangen wird, um alle Elemente und Beziehungen des Systems zu erfassen.^[37] Systemdenken vollzieht sich nach Schmidt in sechs Schritten.^[38] Am Anfang werden Systemgrenzen gebildet und es wird festgelegt welche Elemente zum System gehören und welche Elemente als externe Umwelt betrachtet werden. Die außerhalb liegenden Elemente und Systeme (Umsysteme) bilden den so genannten Problemkreis. Da ein System nicht losgelöst von seiner Umwelt existiert, werden im zweiten Schritt die Einflussgrößen ermittelt. Diese Einflussgrößen gliedern sich in Restriktionen und Rahmenbedingungen, die innerhalb oder außerhalb des Systems existieren können. Restriktionen schränken die Möglichkeiten des Systems ein und haben einen direkten Einfluss auf die Abläufe und Möglichkeiten des Systems. Rahmenbedingungen sind Gegebenheiten, welche vom System zu berücksichtigen sind. Im dritten Schritt werden die Unter- und Teilsysteme definiert. Teilsysteme sind dabei eine Menge von Elementen, welche sich durch Gemeinsamkeiten oder durch bestimmte Beziehungsarten auszeichnen. Untersysteme hingegen stellen eine Menge aus beliebigen Elementen und Beziehungen dar, die sich aus dem Gesamtsystem definieren lässt. Der nächste Schritt besteht in der Definition von Schnittstellen zwischen dem System und der Umwelt. Auf diese Weise können die Abhängigkeiten zwischen den Elementen im System und den Umsystemen aufgedeckt werden. Die letzten beiden Schritte bestehen in der Analyse der Unter- und Teilsysteme, sowie der Ermittlung von Gemeinsamkeiten.

Nachfolgend werden nun zwei Ansätze aus der Literatur behandelt, mit welchen aufbauend auf der systemtheoretischen Sichtweise ein IS betrachtet und untersucht werden kann.

2.1.2.1 Der sozio-technische Ansatz

Im sozio-technischen Ansatz werden Informationssysteme aus Sicht der Systemtheorie als offene, zweckbezogene und dynamische Systeme gesehen.^[39] Ihr Zweck liegt allgemein in der Unterstützung der betrieblichen Aufgabenerfüllung.^[40] Die Offenheit entsteht durch die Interaktion der Untersysteme und Elemente mit der Umwelt, die sich in Abhängigkeit dieser Interaktionen verhalten und reagieren^[41]. Dies führt zu Dynamik. Betrachtet man IS aus Sicht der Systemtheorie als Ganzes, so lässt sich feststellen, dass IS sozio-technische Systeme sind, d.h. ein IS lässt sich in die Untersysteme Mensch und Technik zerlegen.^[42] Schematisch lässt sich dies in Abbildung 2.2 zeigen.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Teubner (1999), S.26

Abbildung 2.2: Schalenmodell des Informationssystems

Das Schema verdeutlicht, dass der Mensch als Benutzer auf alle Aspekte des Anwendungssystems zugreift.^[43] Im Folgenden werden kurz die Untersysteme Mensch und Technik betrachtet.

2.1.2.1.1 Technik/Anwendungssysteme

Das erste Untersystem stellt die zugrunde liegende Technik eines IS dar, die sich in Software- und Hardwaresystem aufteilt. Das Softwaresystem umfasst die Anwendungssoftware (z.B. MS Office) und die Basissoftware (z.B. Betriebssystem). Das Hardwaresystem besteht aus den physischen Komponenten, wie Computer, Speichermedien und Netzwerke.^[44] Zusammen ergeben die beiden Systeme das Anwendungssystem.^[45] Teubner systematisiert die in IS verwendete Technik in Informations- und Kommunikationstechnik, wie in Abbildung 2.3 dargestellt.^[46] Im Folgenden wird auf die Informations- und Kommunikationstechnik mit der Abkürzung IT verwiesen.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Teubner (1999), S.22

Abbildung 2.3: Systematisierung der Informations- und Kommunikationstechnik

Zwei weitere wichtige Konzepte stellt die IT-Infrastruktur und die IT-Architektur dar. Die IT-Infrastruktur besteht aus der Hardware, der Basissoftware, der Middleware und den Anwendungsplattformen, sowie den Kommunikationsnetzen und –diensten.^[47] Sie bedarf des Weiteren einer Planung und eines genauen Konzeptes, wofür die IT-Architektur verantwortlich ist. Eine IT-Architektur kann als die technische Blaupause eines Unternehmens verstanden werden.^[48] Diese Blaupause kann dabei wie eine Art Landkarte für die Informationsbedürfnisse und technischen Anforderungen des Unternehmens aufgefasst werden.^[49] Die IT Architektur stellt auch das Design der Schlüsselanwendungssysteme des Unternehmens dar und beschreibt die unternehmensspezifische Ausprägung der IT Infrastruktur.^[50]

2.1.2.1.2 Menschen und Organisation

Das zweite Untersystem bilden Menschen und die Organisation, die sie sich in einem Unternehmen gegeben haben. Dabei wird unter einer Organisation meist der Aufbau eines Objektes verstanden.^[51] Die betriebswirtschaftliche Organisationslehre bietet dabei zwei Möglichkeiten den Aufbau und die Struktur eines Unternehmens zu betrachten.^[52] Zum einen ist dies die instrumentale Sichtweise, welche die Anordnung und Gestalt von Elementen, sowie den Schaffensprozess dieser Ordnung umschließt. Zum anderen die institutionelle Sichtweise, welche das Gebilde und das Ganze an sich betrachtet.^[53] Im Rahmen dieser Untersuchung werden mit dem Begriff Organisation auch zwei weitere Bedeutungen von Laudon und Laudon umschlossen. Die erste ist ein technische Sichtweise und definiert Organisation als „stable, formal social structure that takes resources from the environment and processes them to produce inputs“.^[54] Die zweite Sichtweise ist eine eher verhaltenstheoretische Sichtweise und definiert Organisation als „a collection of rights, privileges, obligations, and responsibilities that are delicately balanced over a period of time through conflict and conflict resolution“.^[55] Die beiden weiteren Bedeutungen erleichtern es dem Leser besonders in Kapitel 3 den Kontext zu erfassen.

2.1.2.2 Der sprachkritische Ansatz

Der zweite systemtheoretische Ansatz, der im Rahmen dieser Untersuchung vorgestellt werden soll ist der sprachkritische Ansatz. Der sprachkritische Ansatz betrachtet ein IS auch aus Sicht der Systemtheorie, konzentriert sich jedoch auf den Aspekt Sprache. Da nach der obigen Definition in IS Information und Kommunikation von Maschinen und Menschen die Hauptrolle spielen, gehört die Fähigkeit des Menschen verständlich und sinnvoll kommunizieren zu können mit zur Problematik eines IS.^[56] Theoretische Grundlage des sprachkritischen Ansatzes bildet die Fähigkeit des Menschen Sprachen in unbekannten Situationen anzuwenden und gegebenenfalls zu erweitern.^[57] Die grundlegenden theoretischen Strukturen, des sinnvollen Redens, beschreibt die Logische Propädeutik von Kamlah und Lorenzen.^[58] Findet sich eine Gruppe von Sprechern zusammen, so wird diese als Sprachgemeinschaft bezeichnet.^[59] Ursprünglich stammt dieser Begriff aus der älteren dialektologischen Theorienbildung und verwies auf Gruppen von Menschen, die im selben räumlichen Kontinuum leben. Durch die Entwicklung der Soziolinguistik bekam der Begriff Sprachgemeinschaft einen starken hierarchischen Aspekt, so dass aus diesem Verständnis große Sprachgemeinschaften in kleinere zerfallen. Die Anwendung des Begriffes kann nicht nur auf geographische Gruppierungen, sondern auch auf soziale Netze ausgedehnt werden und Sprachgemeinschaften können somit auch als Interaktionsgemeinschaften auffasst werden. Vor diesem Hintergrund erklärt sich, warum Holten den sprachkritischen Ansatz mit Beispielen aus dem Supply Chain Management verdeutlicht, welche die Integration von Geschäftsprozessen zur Interaktion von Unternehmen behandelt.^[60]

Sprechen in einer solchen Sprachgemeinschaft bedeutet, dass unverständliches Reden von den Sprechern zu vermeiden ist.^[61] Das aktuelle flüchtige Sprechen von Menschen wird als „Rede“ bezeichnet.^[62] Mit dem Begriff „Sprache“ werden im sprachkritischen Ansatz erlernte Handlungsgewohnheiten bezeichnet, wie z.B. Sprachgewohnheiten, die jederzeit kombiniert werden können, um daraus eine „Rede“ zu machen.^[63] Damit sich Menschen verstehen können, werden so genannte Zeigehandlungen verwendet, die in standardisierter Form (Schema), wie ein Werkzeug benutzt werden können.^[64] Diese Schemata von Zeigehandlungen treten z.B. als Wörter auf.^[65] Die spezielle (Zeige-)Handlung einem Gegenstand ein Wort zu zuordnen („Das ist ein Baum“), nennt man Prädikation und ist ein Grundkonzept der Logischen Propädeutik.^[66] Jedem Wort ist somit eine Bedeutung inhärent und wenn dem Sprecher die Bedeutung bekannt ist, kann dieser auch andere Wörter mit der gleichen Bedeutung verwenden (Synonyme).^[67]

Wenn sich Sprachgemeinschaften bilden, müssen sich die Sprecher beim Sprechen, der aktuellen „Rede“ über zwei Dinge im klaren sein, nämlich über Wort und Bedeutung.^[68] Dieser Vorgang geschieht in zwei Abstraktionsstufen: Im ersten Schritt wird man sich aus der aktuellen „Rede“ über die einzelnen Wörter klar und extrahiert im zweiten Schritt, dann die Bedeutung der Worte.^[69] Werden spezielle Themen erörtert bedient man sich meist einer Fachsprache in der Fachausdrücke (Termini) zum Einsatz kommen. Die Menge aller Termini wird Terminologie genannt.^[70] Dieser präzise Einsatz von Sprache wird in Kapitel 3.1.1 und Kapitel 4.1 wieder aufgegriffen, wenn zum einen die Ursachen und Wirkungen vom Komplexität betrachtet werden und zum anderen die Messbarkeit von Komplexität.

Damit ein System überlebensfähig ist, muss es auf Einwirkungen von außen mit sinnvollen Maßnahmen reagieren können.^[71] Unter diese Reaktionen fallen auch das Sprechen und die Möglichkeit die eigene Terminologie sinnvoll erweitern zu können.^[72] Es kann gezeigt werden, dass ein Informationssystem eine Sprachgemeinschaft darstellt.^[73] Für die formalen und ausführlichen Beweise, sei der geneigte Leser auf die einschlägige Literatur verwiesen.^[74] Es lässt sich sogar zeigen, dass IS autopoietische Systeme sind, also Systeme, die ihre Ordnung selbst erschaffen^[75] und dass sie sogar soziale Systeme im Sinne Luhmanns sind.^[76] IS können damit nur indirekt gestaltet werden, da sie sich als autopoietische Systeme nicht nach externen Vorschriften richten.^[77] Diese Merkmale kommen besonders in Kapitel 5 zum Tragen.

2.2 Informationssystem-Entwicklungsprojekte

Nachdem der Leser im zurückliegenden Abschnitt ein allgemeines Verständnis von IS gewinnen konnte stellt dieser Abschnitt die allgemeinen Konstrukte und Abläufe im Rahmen von Projekten vor, welche die Erstellung eines IS zum Ziel haben. Am Anfang der Darstellung von ebendiesen Informationssystem-Entwicklungsprojekten (ISDP) werden der IS-Projektablauf und das Projektmanagement von ISDP vorgestellt. Aus Abbildung 2.4 geht hervor, dass es allgemein zwei Wege gibt ein IS in einem Unternehmen zu installieren. Beim Beschreiten des ersten Weges (Individualsoftware) werden IS im Unternehmen selbst von speziellen Projektteams und Spezialisten entworfen und umgesetzt. Dabei werden diese System auf die Bedürfnisse des Unternehmens zugeschnitten.^[78] Besonders in den achtziger Jahren wurde ein großer Aufwand betrieben, um Methodiken und Vorgehensmodelle zu erstellen, die alle Dimensionen der IS-Entwicklung (ISD) mit einbeziehen. Große Unternehmen und Organisationen entwickeln ihre IS meist selbst anhand bestimmter Methodiken und Vorgehensweisen. Aufgrund der enormen Vielzahl an Modellen und Vorgehensweisen werden in diesem Kapitel nur drei Vorgehensmodelle betrachtet. Der zweite Weg ist die Anschaffung von Standardsoftware, wie z.B. SAP oder Oracle, die danach durch verschiedene Projekte in den jeweiligen Unternehmens- und Organisationskontext eingepasst wird. Da bei der Entwicklung von IS ein klarer Trend zur Anschaffung von Standardsoftware zu erkennen ist, wird im Anschluss zu den Vorgehensmodellen kurz auf den Beschaffungsprozess solcher Standardsoftware eingegangen.^[79]

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Vgl.Stahlknecht; Hasenkamp (2005), S.218

Abbildung 2.4: Pfade der IS-Einführung

2.2.1 Informationssystem-Entwicklungsprojekte – Ablauf und Management

2.2.1.1 Projektablauf

Eine Definition für ein Projekt stammt von Jenny:

„Projekte sind in sich geschlossene, komplexe Aufträge, deren Erfüllung eine Organisation bedingt, die für die Umsetzung der Tätigkeiten eine Methode anwendet, mit der alle Arbeiten geplant, gesteuert, durchgeführt und kontrolliert werden können.“ Jenny (2001) S.58

Der erste Schritt eines neuen IS-Projektes ist die Aufnahme in das sog. IS-Projektportfolio des Unternehmens. Dafür legt jedes Unternehmen seine eigenen, individuellen Kriterien an das Projekt an.^[80] Das IS-Projektportfolio gibt nicht nur Auskunft über die laufenden und zukünftigen Projekte, sondern auch über Koordination und Ressourcenzuteilung der Projekte.^[81] Damit ein Projekt genehmigt wird, durchläuft es vor Beginn mehrere Schritte. Als erstes wird ein Projektantrag geschrieben, der mit den strategischen, operativen und dispositiven Zielen und Gegebenheiten des Unternehmens abgeglichen wird. Anschließend erfolgt eine Bewertung des Antrages auf Konsistenz, Vollständigkeit und Projektcharakter. Wichtige Merkmale sind u.a., Umfang, Dauer, Kosten, Risiken und Komplexität des Projektes. Auf die Bewertung folgt eine Machbarkeitsstudie, welche Durchführbarkeit und Wirtschaftlichkeit des beantragten Projektes evaluiert und den Zeitaufwand abschätzt. Projektanträge mit positiver Bewertung werden in die IS-Entwicklungsplanung eingebunden, welche die Reihenfolge und Ressourcen der Projekte festlegt. Im Rahmen dieser Planung werden neben Wirtschaftlichkeitsbetrachtungen, z.B. in Form von Rentabilitätsrechnungen, auch die Risikoanalyse und die Personal- und Finanzplanung durchgeführt.^[82] Hat der Projektantrag alle Kriterien erfüllt, erfolgt die Projektfreigabe und während des Projektes die IS-Entwicklungskontrolle.^[83] Diese und alle folgenden Schritte werden im Projektabwicklungszyklus zusammengefasst.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Jenny (2001), S.460

Abbildung 2.5: Projektabwicklungszyklus

Die Projektinitialisierung beginnt meist im Rahmen eines Workshops, in dessen erster Sitzung die Systemabgrenzung vorgenommen und die Situation analysiert wird, indem Umfang, Einflussgrößen, Umsysteme und die Komplexität festgestellt werden.^[84] Für die Projektklassifizierung, die der Transparenz des zu formulierenden Antrages dient, werden Projekteigenschaften, wie Wichtigkeit, Dringlichkeit, Risiken, etc. ermittelt.^[85] Den letzten Schwerpunkt der Initialisierung bildet die Erstellung eines Projektantrages, dessen zeitlicher Aufwand zur Erstellung mit dem Umfang zunimmt.^[86] Der Projektantrag legt unter anderem den Grund, den Nutzen, die Kosten, die organisatorischen Auswirkungen, sowie die Risiken, die Komplexität und die Intensität des Projektes dar. Abschließend wird der Projektantrag zur Antragsprüfung beim Projektportfolioverwalter vorgelegt, der Vollständigkeit, Richtigkeit, Dauer, etc. überprüft und nach einer Bewertung aller Projektaspekte den Antrag genehmigt oder ablehnt.

In der anschließenden Projektdefinition werden zuerst die Projektziele erarbeitet, indem die Punkte des Anforderungskataloges in Systemziele überführt werden.^[87] Die Systemziele werden weiter in finanzielle Ziele, funktionelle Ziele und soziale Ziele aufgegliedert. Anschließend erfolgt die erste Einteilung in Etappenziele. System- und Etappenziele bilden zusammen einen umfassenden Zielkatalog, welcher in Verbindung mit der Gesamtprojektplanung das Kernelement für die anschließenden Projektarbeiten bildet. Im zweiten Schritt wird die Projektplanung und –abgrenzung durchgeführt. Dabei werden Start- und Endtermine des gesamten Projektes und der einzelnen Phasen festgelegt; genauere Schätzungen des Projektaufwandes und ein Budgetantrag werden ebenfalls in diesem Schritt erstellt. Weitere Schritte sind die Projektgründung, bei welcher die Verantwortlichkeiten festgelegt werden und die Prozessorganisation, die den Ablauf der einzelnen Prozesse festlegt. Die letzten beiden Schritte stellen die Projektorganisation und die Erstellung des Projektauftrages dar. Die Projektorganisation umfasst die Auswahl von geeigneten Teammitglieder und einer geeigneten Organisationsstruktur für das Projekt.^[88] Abschließend werden alle Ergebnisse in einem Projektauftrag erfasst, der wieder zur Genehmigung vorgelegt wird.^[89]

Nach erfolgter Projektfreigabe beginnt die Projektplanung. Diese wird sich bis zum Ende des Projektes durchziehen, da die verschiedenen Einflussgrößen und Faktoren, die auf das Projekt wirken, einem ständigen Wandel unterliegen und in bestimmten Abständen in Form einer neuen Planung berücksichtigt werden müssen.^[90] In dieser Phase werden zuerst die Planungsarten, Planungsinstrumente, Planungszuständigkeiten und Planungszeitpunkte festgelegt.^[91] Das Resultat dieser Schritte stellt in den meisten Fällen eine beträchtliche Anzahl verschiedenster Pläne dar, die das Projektvorhaben aus unterschiedlichen Perspektiven mit dem jeweils erforderlichen Detaillierungsgrad beschreiben.^[92]

Der Vorgehensweise eines Projektes liegt meist ein Phasen- oder Vorgehensmodelle zu Grunde, die vom jeweiligen Unternehmen vorgeschrieben werden.^[93] Einen kurzen Überblick über diese Vorgehensmodelle erhält der Leser in Kapitel 2.2.2. Je nach Projektart und –umfang kommen unterschiedliche Modelle zur Anwendung, die in dieser Untersuchung jedoch nicht näher beschreiben werden.

Jede Phase des Projektes sollte nach einem Gesamtkonzept (Prüfplan) kontrolliert werden.^[94] Der Prüfplan sollte nicht nur die Prüfstrategien, sondern auch die Prüfzeitpunkte enthalten.^[95] Damit die Kontrolle konsistent erfolgen kann, sollte das gesamte Projekt in Kontrollgruppen und –bereiche aufgeteilt werden.^[96] Die Kontrolle selbst teilt sich dabei in die Planungskontrolle und die Realisierungskontrolle auf.^[97]

Der Projektabschluss beginnt meist mit der Produktabnahme durch den Auftraggeber. Bei IS-Projekten heißt dieser Abschnitt meist Systemabschluss-Kontrolle.^[98] Dabei werden Funktionalität und Beständigkeit geprüft, sowie eine Akzeptanzprüfung bei den zukünftigen Benutzern durchgeführt. Eine weitere Schritt des Projektabschlusses besteht in der Projektabschluss-Beurteilung, in der abschließend der gesamte Projektverlauf beleuchtet wird. Die abschließende Beurteilung umfasst die Beurteilung des Systems, als auch des gesamten Abwicklungsprozesses. Es folgen meist die Erstellung eines Projektabschlussberichtes, sowie die Erfahrungssicherung. Das offizielle Ende des Projektes erfolgt mit der Projektauflösung. Es wird der Antrag auf Projektabschluss gestellt und die Projekt- und Systemdokumentation werden den zukünftigen Verwendern des Systems übergeben.

2.2.1.2 Projektmanagement

Die Aufgabe der Koordination und Kontrolle der einzelnen Abläufe in einem Projekt obliegt dem Projektmanagement. The Institute of Electrical and Electronics Engineers (IEEE) definiert Projektmanagement in Ihrem Standard IEEE 1490-2003 durch die Übernahme des Standards des Project Management Institutes (PMI) „A Guide to Project Management Body of Knowledge”.^[99] Dieser Standard definiert Projektmanagement als “the application of knowledge, skills, tools and techniques to project activities to meet project requirements”^[100]. Wichtige Aufgaben des Projektmanagements sind die Planung und Koordination, das Motivieren, Anleiten und Kontrollieren der Mitarbeiter, das Schützen des Projektes von den Umsystemen, sowie das Erkennen und Beheben von Problemen, bevor diese akut werden.^[101] Das Projektmanagement (PM) eines IS-Projektes lässt sich in drei Teile gliedern: institutionelles PM, funktionelles PM und die Projektführung.^[102] Das Ziel des institutionellen Projektmanagements ist eine optimale Arbeitsleistung durch den Aufbau einer Institution, die sowohl flexibel, als auch stabil ist.^[103] Die Hauptaufgaben umfassen die Auswahl der Organisationsform der Projektgruppe, die Festlegung der Instanzen und Stellen, sowie das Einrichten des Projektinformationssystems, des Projektdokumentationssystem und des Sachmittelsystems.^[104] Das funktionale Projektmanagement beinhaltet dagegen die Projektplanung, die Projektsteuerung und Koordination, sowie die Überwachung und Kontrolle.^[105] Aus Sicht der Systemtheorie kann der Vorgang der Projektabwicklung als das Verändern eines Systems (bestehendes IS bzw. Unternehmen) mittels eines anderen Systems (ISDP) aufgefasst werden.^[106] Aufgrund des Systemcharakters sieht sich das ISDP immer einer Reihe von Rahmenbedingungen gegenüber, die entwicklungsbezogen, projektbezogen, firmenbezogen, personal- und anwendungsbezogen oder produktbezogen sein können.^[107] Eine vollständige Auflistung findet der geneigte Leser in Anhang A, die der Orientierung dient, um die in Kapitel 3 beschriebenen Einflüsse einordnen zu können. Neben den Rahmenbedingungen treten auch eine Reihe von Restriktionen auf, die umweltbezogen, firmenbezogen, risikobezogen oder systembezogen sein können.^[108] Eine Auflistung bzgl. der Restriktionen findet der geneigte Leser in Anhang B.

2.2.2 Vorgehensmodelle

In der 4. Phase des Projektablaufzykluses aus Abbildung 2.5 wird die Anwendung eines geeigneten Phasenmodells vorgeschlagen. Solche Phasenmodelle werden auch Vorgehensmodelle genannt. Da diese Vorgehensmodelle essentiell für die Arbeit in einem ISDP sind, werden im folgenden drei ausgesuchte Vorgehensmodelle besprochen.

Die Wasserfallmethode, dargestellt in Abbildung 2.6, unterteilt die gesamte Systementwicklung in verschiedene Phasen, die sequentiell bearbeitet werden müssen, wobei zu erst eine Phase abgeschlossen sein muss, bevor die nächste in Angriff genommen werden kann, da der Output der abgeschlossenen Phase den Input für die darauf folgende darstellt.^[109] Jede dieser Phasen oder Stufen unterteilt sich dabei in zwei Teile. Der erste Teil beinhaltet die eigentliche Arbeit, während der zweite die Überprüfung und Abstimmung der Arbeiten mit den vorgegebenen Anforderungen und Zielen ausfüllt. Nacharbeiten finden meist in der aktuellen Stufe statt, in der sich das Projekt befindet. Somit eignet sich dieser Ansatz nur für Projekte in denen minimale Nacharbeiten auftreten, die Anforderungen bekannt sind und die Umwelt stabil ist.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Vgl.Boehm (1988), S.62

Abbildung 2.6: Wasserfallmodell

Dagegen beinhaltet das Spiralmodell, dargestellt in Abbildung 2.7, ein iteratives Vorgehen.^[110] Ändern sich die Umgebung und die Anforderungen schnell, müssen die Schritte des Wasserfallmodells mehrfach durchlaufen werden. Dagegen startet das Projekt im Spiralmodell in der Mitte der Spirale und durchläuft immer wieder die vier Quadranten (1) Bestimmung der Ziele, Alternativen und Randbedingungen (2) Einschätzung und Bewertung der Alternativen sowie die Identifikation und das Beheben von Risiken (3) Entwicklung und Überprüfung (4) Planung der nächsten Phase.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Vgl.Boehm (1988), S.64

Abbildung 2.7: Spiralmodell

Eine relativ neues Vorgehensmodell stellt der Rational Unified Process (RUP) der Firma IBM (früher Rational Software) dar.^[111] RUP unterscheidet sich von vielen anderen Vorgehensmodellen in seiner fallgetriebenen, iterativen, architekturzentrierten und inkrementellen Art und Weise.^[112] Es besitzt neun Arbeitsabläufe, die sich jeweils in vier Phasen (Anfang, Ausarbeitung, Konstruktion, Übergang) aufteilen und parallel verlaufen.^[113] Die Arbeitsabläufe sind in Abbildung 2.8 graphisch dargestellt. Der erste Arbeitsablauf (Business modelling) beschäftigt sich mit der Erstellung und Modellierung des Geschäftsmodells.^[114] Der zweite Ablauf (Requirements) sammelt von allen Beteiligten (Stakeholdern) funktionale und nicht-funktionale Anforderungen ein und definiert die Grenzen des Systems.^[115] Der nächste Ablauf (Analysis and design) analysiert die funktionalen Anforderungen auf einer logischen Ebene (plattformunabhängig) und wandelt die analysierten Anforderungen in Spezifikationen für die Implementierung um.^[116] Der Implementierungsablauf (Implementation) setzt die Anforderungen und Entwürfe in konkrete implementierbare Komponenten um.^[117] Anschließend erfolgt im folgenden Ablauf (Test) ein ausgiebiges Testen der Komponenten und eine Überprüfung, ob die konkreten Anforderungen erfüllt sind.^[118] Im sechsten Ablauf (Deployment) erfolgt die Aufstellung der Komponenten.^[119] Die letzten drei Arbeitsabläufe (Configuration and Change Management, Project Management, Environment) haben zu den anderen Abläufen eine übergeordnete Position, da sie größtenteils administrative Aufgaben wahrnehmen. Der erste der übergeordneten Arbeitsabläufe (Configuration and Change Management) stellt die Integrität des Projektes sicher, in dem Veränderungen und Konfigurationen zentral verwaltet werden.^[120] Der zweite übergeordnete Ablauf (Project Management) beschäftigt sich ausschließlich mit den koordinatorischen und verwaltungstechnischen Aufgaben, die im Rahmen des Projektmanagements anfallen.^[121] Der letzte, der übergeordneten Abläufe (Environment), unterstützt das Projekt mit relevanten Methoden, Prozessen und Werkzeugen innerhalb der Organisation.^[122]

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Vgl.Avison; Fitzgerald (2003), S.427

Abbildung 2.8: Rational Unified Process

Die vorgestellten Vorgehensmodelle sind nur ein kleiner Ausschnitt aus der enormen Vielfalt an Modellen und verdeutlichen dem Leser, wie sich diese Modelle im Laufe der Zeit weiterentwickelt haben.

2.2.3 Anschaffungsprozess von Standardsoftware

Nach der Behandlung der Vorgehensmodelle, die meist bei der Entwicklung von Individualsoftware eingesetzt werden, wird nun kurz der Anschaffungsprozess von Standardsoftware betrachtet, der sich auch innerhalb eines Projektes vollzieht.

Zu Beginn des Projektes werden die einzelnen Hersteller eingeladen ihre Vorschläge für die technische Umsetzung des Projektes zu präsentieren.^[123] Danach konzentriert sich das Projektteam auf zwei bis drei Hersteller, die in die engere Auswahl genommen werden. Mit diesen Herstellern wird ein so genannter „proof-of-concept“ durchgeführt, d.h. die technischen Lösungen dieser Anbieter werden zwei bis drei Tage lang mit eigenen Unternehmensdaten getestet. Anschließend wird in einem Workshop entschieden, welcher Anbieter den Auftrag erhält. Viele Unternehmen entscheiden sich meist für einen Anbieter.

Das Department of Trade and Industry in Großbritannien hat einen generischen Beschaffungszyklus für die Beschaffung komplexer IT-Systeme entwickelt.^[124] Der Kreislauf, dargestellt in Abbildung 2.9, beginnt bei der Erhebung der Anforderungen für das Unternehmen oder der Abteilung (business needs).^[125] Andere Modelle aus der Literatur weisen eine ähnlich Herangehensweise auf.^[126]

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Vgl.DTI (1995) zit. n. James (2002), S.186

Abbildung 2.9: Beschaffungszyklus für Standardsoftware

2.3 Komplexität

Zum Thema Komplexität herrscht in der Literatur eine Vielfalt an Meinungen, Konzepten und Gedanken, deren Darstellung den Rahmen dieser wissenschaftlichen Arbeit bei weitem sprengen würde. Daher wird der Leser im folgenden Abschnitt mit einzelnen wissenschaftlichen Auffassungen und Konzepten vertraut gemacht. Zuerst wird eine Auswahl an Definitionen und Konzepten für Komplexität dargestellt. Danach folgt eine kurze Betrachtung der Komplexitätstheorie und Komplexitätsforschung, bevor auf ein zentrales Konstrukt der Komplexitätsforschung (Komplexe Systeme) eingegangen wird. Anschließend werden zwei Rahmenwerke aus der Literatur vorgestellt, die versuchen die Komplexität von ISDP zu erfassen und zu erklären.

2.3.1 Allgemeine Definitionen und Konzepte von Komplexität

Die Brockhaus-Enzyklopädie definiert das Adjektiv „komplex“ wie folgt: „ komplex [lat., zu complecti, complexus „umschlingen, „umfassen“], vielschichtig, viele verschiedene Dinge umfassend“.^[127] Eine Definition zum Substantiv Komplexität findet sich nicht. Dies spiegelt die aktuelle Lage wider, da es bis jetzt noch keine allgemeine Definition für den Begriff Komplexität gibt.^[128] Im Gegensatz zu den umgangs- und alltagssprachlichen Verwendungen des Begriffes Komplexität, wie aus der Brockhaus-Enzyklopädie zitiert, sollen hier verschiedene Definitionen und Konzepte aus der wissenschaftlichen Literatur, sowie deren Kritik durch Edmonds vorgestellt werden. Die vorgestellten Konzepte sollen weder einen Anspruch auf Vollständigkeit oder einer umfassenden Definition erheben, sondern dem Leser einen Einblick bieten, wie die wissenschaftliche Literatur den Begriff „Komplexität“ definiert.

Verschiedene Konzepte, die von Edmonds zusammengetragen wurden, versuchen alle dem Phänomen Komplexität näher zu kommen. Dazu gehören die Konzepte Größe, Unwissenheit, minimale Beschreibungsgröße, Varietät, sowie das Gegensatzpaar Ordnung und Unordnung.^[129]

Die Größe oder das Ausmaß wird meist als Indikator für Komplexität verwendet, indem mit der Größe eines bestimmten Objektes auch dessen Komplexität verknüpft wird.^[130] Dementsprechend sind größere Objekte komplexer als kleinere. Größe allein reicht jedoch nicht aus, da man im Rahmen von Komplexität häufig auch von der Verbundenheit der Elemente spricht und diese wird durch das Konzept „Größe“ nicht erfasst, sondern teilweise nur impliziert. Der Terminus Komplexität wird auch zur Beschreibung von Gegenständen und Systemen verwendet, die noch nicht erschlossen sind, wie z.B. das menschliche Gehirn, und damit (noch) im Bereich der Unkenntnis verbleiben. Die Feststellung von Unkenntnis mit Komplexität gleichzusetzen ist jedoch nicht besonders hilfreich, da Komplexität Unkenntnis oder erschwerte Erfassbarkeit begünstigt, jedoch die Präsenz von Unkenntnis keine Rückschlüsse auf Komplexität zulässt oder Komplexität damit erfassbarer macht.Ein weiteres Konzept welches mit Komplexität in Verbindung gebracht wird, ist das Konzept der minimalen Beschreibungslänge. Dabei wird ein Objekt oder ein Sachverhalt durch eine bestimmte Sprache beschrieben und je länger die Beschreibung ausfällt, desto komplizierter ist das Objekt oder der Sachverhalt. Die minimale Beschreibungsform ist eng mit der Informationstheorie verbunden und besitzt in der Informatik eine weite Verbreitung. Es kann jedoch bis heute nicht bewiesen werden, dass die minimale Beschreibung auch wirklich einfacher ist, wie das System, welches sie beschreiben soll.^[131]

Die Varietät beschreibt die Anzahl der Zustände, die ein System annehmen kann.^[132] Dabei stellt die Varietät keine einem System inhärente Eigenschaft dar, sondern muss in ihrer Definition immer die Perspektive des Betrachters berücksichtigen.^[133] Die Größe „Varietät“ ist ein weiteres wichtiges Konzept, allerdings stellt die Varietät nur ein notwendiges jedoch kein hinreichendes Kriterium für Komplexität dar.^[134]

Das letzte Konzept, das Edmonds betrachtet ist das Gegensatzpaar Ordnung und Unordnung. Aber auch Ordnung und Unordnung sind nicht besonders geeignet, da ein ungeordnetes System aus kleineren geordneten Systemen zusammengesetzt sein kann oder die Ordnung eines Systems nicht erkannt wird und somit fälschlicherweise als Unordnung bezeichnet wird.^[135]

Neben den oben genannten verschiedenen Konzepten wurde auch ein Menge an Definitionen für Komplexität durch die Literatur erschaffen. Fünf dieser Konzepte werden nachfolgend kurz vorgestellt werden. Die computerbezogene Komplexität bezeichnet die Menge an Ressourcen, die ein Computer benötigt (z.B. Zeit oder Speicher), um eine bestimmte Klasse an Problemen zu lösen.^[136] Leider besteht auf der Suche nach einer Definition von Komplexität das Problem weniger im Lösen bestimmter Probleme als viel mehr in Suche oder dem Erschaffen des Programms, welches zum Lösen nötig wäre. Ein weiteres Konzept welches in der Informatik sehr bekannt ist, stellt die Kolmogorov-Komplexität dar. Diese gibt die minimale Länge eines Programms an, damit eine so genannte Turingmaschine^[137] ein bestimmtes Muster hervorbringt. Dieses Komplexitätsmaß geht allerdings mit der Kompressionsmöglichkeit einer bestimmter Darstellungsweise einher und hat daher wenig mit den tatsächlichen Sachverhalten zu tun. Bennets logische Tiefe gibt an, wie viele Ressourcen eines Computers benötigt werden, um ein Programm minimaler Länge zu bearbeiten. Dieses Maß stellt eine Mischung aus der Kolmogorov-Komplexität und der computerbezogenen Komplexität dar. Es misst jedoch eher die Komplexität des Schaffensprozesses, jedoch nicht die Komplexität des Resultates. Aus der Perspektive der Ordnung misst Kauffman Komplexität als die Anzahl der widersprüchlichen Bedingungen bzw. Randbedingungen unter denen ein System agiert bzw. entsteht.^[138]

Eine konkrete Liste mit Kriterien, die bei Vorhandensein von Komplexität erfüllt sind wurde von Yates aufgestellt. Nach dieser Liste müssen folgende fünf Kriterien zutreffen, damit Komplexität vorhanden ist:^[139]

- Eine signifikante Anzahl an Wechselbeziehungen oder Interaktionen
- Eine große Anzahl an Elementen
- Nicht-Linearität
- Gebrochene oder defekte Symmetrie
- Nichtholonome Randbedingungen

Für die Unterscheidung zwischen Komplexität und Chaos ist anzumerken, dass die Chaostheorie sich auf Systeme konzentriert, in denen unbedeutende Störungen zu enormen Konsequenzen führen.^[140] Somit nimmt die Komplexität ihren Platz zwischen zu wenig und zu viel Ordnung, nämlich am Rande des Chaos, ein.^[141] Dies wird in Abbildung 2.10 noch einmal graphisch veranschaulicht.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Edmonds (1999b),S.5

Abbildung 2.10: Verhältnis von Komplexität zu Unordnung

2.3.2 Komplexitätstheorie und Komplexitätsforschung

Bis jetzt hat die Forschung eine große Zahl an Theorien über Komplexität im Allgemeinen und in verschiedensten Fachrichtungen geschaffen. Der Begriff Komplexitätstheorie (engl. complexity theory) bezeichnet allerdings bis heute keine einheitliche wissenschaftliche Forschungsrichtung.^[142] Unter dem Begriff Komplexitätsforschung (engl. complexity research) hat sich dagegen eine Ansammlung an Theorien und Ansätzen zusammengefunden, deren Fokus hauptsächlich auf komplexen Systemen liegt. Ein Ansatz die verschiedenen Theorien zu systematisieren stammt von Manson, der eine dreiteilige Aufteilung der Komplexitätsansätze in algorithmische, deterministische und aggregierte Komplexität vornimmt. Alle drei Komplexitäten beschäftigen sich jedoch damit, wie man durch Bezug auf die einzelnen Elemente die Natur eines Systems beschreiben kann, ohne Teile weglassen zu müssen.^[143]

Die algorithmische Komplexität umfasst die mathematische Komplexitätstheorie und die Informationstheorie und wählt den Ansatz, dass die Komplexität eines Systems in der Schwierigkeit seiner Beschreibung liegt.^[144] Im Bereich der algorithmischen Komplexität gibt es zwei vorherrschende Konzepte zur Messung bzw. Erfassung von Komplexität. Das erste Konzept zeigt an, welcher Aufwand notwendig ist, um ein bestimmtes mathematisches Problem zu lösen. Das zweite Konzept der algorithmischen Komplexität gründet sich auf die Informationstheorie und gibt den einfachsten Computeralgorithmus an, der in der Lage ist, das Verhalten eines Systems zu reproduzieren.

Die deterministische Komplexität umfasst die Chaostheorie und die Katastrophentheorie, die davon ausgehen, dass durch Wechselbeziehungen zwischen zwei oder drei Schlüsselparametern ein weitgehend stabiles System entstehen kann, welches jedoch anfällig für plötzliche Unterbrechungen und Störungen ist.^[145] Die deterministische Komplexität zeichnet sich durch vier Eigenschaften aus: (1) Rückkopplung, (2) Empfindlichkeit bzgl. der Anfangsbedingungen und Verzweigungen, (3) Gebrauch von deterministischer Mathematik und mathematischen Attraktoren und (4) der konzeptionellen Vorstellung eines deterministischen Chaos und fremden Attraktoren. Unter einem Attraktor versteht man einen bestimmten Wert, auf den sich eine Systemvariable im Laufe der Zeit zu bewegt. Die Eigenschaft der deterministischen Mathematik geht davon aus, dass sich das Verhalten des komplexen Systems durch wenige Schlüsselparameter und Gleichungen abbilden lässt. In diese Gleichungen können nun negatives Feedback (Veränderungen in Schlüsselparametern veranlassen das System zu einem stabilen Wert zurückzukehren) und positives Feedback (ein selbstverstärkendes Phänomen in Schlüsselparametern, welches dazuführt, dass das System nicht mehr zum Ausgangspunkt zurückkehrt) eingebaut werden. Die Empfindlichkeit bzgl. der Anfangsbedingungen führt dazu, dass kleinste Veränderungen in den Anfangsbedingungen zu großen nicht-linearen Effekten führen. Diese Phänomen wird umgangssprachlich auch „Schmetterlingseffekt“ genannt. Allerdings schließt die deterministische Komplexität auch die Empfindlichkeit bzgl. Verzweigungen ein, die in Fachkreisen Bifurkationen genannt werden (engl. „bifurcation“).^[146] Eine solche Verzweigung tritt auf, wenn das System plötzlich von einem Attraktor zu einem anderen springt. Die Eigenschaften des deterministischen Chaos und seltsamer Attraktoren (engl. strange attractors) besagen zum einen, dass durch den Aufbau das System bei einem bestimmten Wert ein nicht vorhersehbares Verhalten an den Tag legt und zum anderen, dass das System immer wieder versucht, sich einem bestimmten Attraktor zu nähern, dies jedoch nicht schafft. Das Konzept der deterministischen Komplexität hat bis jetzt nur sehr wenig Anwendung in den Sozialwissenschaften gefunden, da die Methoden aus der Physik stammen und nur äußerst begrenzt auf andere Gebiete übertragbar sind.^[147]

Die aggregierte Komplexität betrachtet wie Systeme mit komplexem Verhalten durch das Zusammenspiel der einzelnen Elemente entstehen.^[148] Sie versucht dabei die Synergien und den Holismus zu erschließen, welche durch das Zusammenspiel der Systemelemente entstehen.^[149] Diese Komplexitätsart umfasst verschiedene Konzepte: (1) Beziehungen zwischen den Systemelementen, (2) die innere Struktur, (3) die Umwelt/Umgebung, (4) Lernen und Gedächtnis, (5) Emergenz und (6) Wandel und Evolution. Das Konzept der Beziehungen zwischen den Systemelementen bildet das Kernstück dieser Komplexitätsart. Es besagt, dass ein komplexes System mehr durch seine Beziehungen als durch seine Elemente charakterisiert ist. Die Beziehungen eines Elementes zu verstehen ist daher sehr schwer und das Verfolgen der Spuren, welche eine Beziehung im System hinterlässt ist nahe zu unmöglich. Solche Beziehungen, die häufig nicht-linearer Natur sind, können mit herkömmlichen Modellierungstechniken nicht abgebildet oder dargestellt werden.^[150] Ein komplexes System hat viele Teilsysteme mit speziellen Aufgaben, allerdings interagieren diese Systeme nur in ihrer lokalen Umgebung mit anderen Systemen, so dass keine Allwissenheit besteht über Vorgänge der anderen Systeme besteht. Die interne Struktur des Systems bestimmt sich aus den verschieden starken Beziehungen, welche die Elemente untereinander aufbauen. Jedes Element kann zu verschiedenen Untersystemen gehören und kann durch den Auf- und Abbau von Beziehungen die interne Struktur des Systems verändern. Ein System verdankt seine Existenz seiner Umwelt oder Umgebung, mit welcher es in ständiger Wechselbeziehung steht. Ein Lerneffekt entsteht durch das Prinzip, dass Systeme, welche sich an die Einwirkungen aus ihrer Umwelt anpassen, Wachstum erfahren. Passieren solche Wechselwirkungen mit der Umwelt häufiger, so fördert dies das Aufkommen und Entstehen der gleichen Elemente und Untersysteme. Durch eine große Vielfalt an Beziehungen und Elementen kann ein System in neuen Situationen bestehen, da es bestimmte Untersysteme gibt, welche die Fähigkeiten besitzen sich an diese neuen Situationen anzupassen. Die Eigenschaft Emergenz besagt, dass ein System Fähigkeiten und Eigenschaften besitzt, welche sich nicht allein durch die analytische Betrachtung der einzelnen Elemente herleiten lassen.^[151] Diese speziellen Qualitäten eines Systems entstehen nur durch das Zusammenspiel der Elemente. Es besteht die Möglichkeit, dass diese Eigenschaften, Fähigkeiten und Phänomene nicht vorhergesagt werden können. Da auch die anderen Elemente ihre Eigenschaften ändern, können höchstens kurzfristige Vorhersagen getroffen werden. Wandel und Evolution sind eindeutige Charakteristika eines komplexen Systems, da dort drei verschiedene Abläufe am Werk sind, welche diesen Prozess antreiben. Der erste Ablauf ist die Selbstorganisation, welche dafür sorgt, dass sich die Struktur ständig verändern kann, damit das System besser mit seiner Umwelt interagieren kann. Der zweite Ablauf ist die Auflösung oder Zerstreuung, die sich ereignet, wenn sich das System in einem Zustand zu starker Unordnung befindet und zu einem anderen Zustand größerer Ordnung führt.^[152] Der dritte und letzte Ablauf hält das System in einem Zustand zwischen Stasis und Zufälligkeit. In diesem selbst geschaffenen, kritischen Zustand befindet sich das System in einer Phase, in der die Geschwindigkeit der inneren Umorganisation fast zu schnell für die Anpassung des Systems abläuft, allerdings die Höhe der Geschwindigkeit notwendig für das Überleben des Systems ist.^[153]

2.3.3 Komplexität im Rahmen eines ISDP

Nachdem die Themen IS, ISDP und Komplexität beschrieben wurden, werden nun im Folgenden verschiedene Ansätze, Meinungen und Erfahrungen zur Schnittmenge dieser Themen vorgestellt. Die Betrachtung dieser Konzepte zeigt dabei auch die unterschiedlichen Betrachtungsweisen von Komplexität in den jeweiligen Fachgebieten. Dabei werden nicht nur Meinungen aus der Literatur, sondern auch aus der Praxis vorgestellt.

Im Bereich Projektmanagement wird Komplexität einer Sache dann zugesprochen, wenn sie besonders viele Einzelteile umfasst, die untereinander in Wechselbeziehungen stehen.^[154] Gerade die Wechselwirkungen der Teile und Teilsysteme machen die Handhabung komplexer Dinge und Sachverhalte schwierig. Thompson unterscheidet allgemein drei verschiedene Wechselwirkungstypen:^[155]

- Parallel: Jedes Element trägt einen bestimmbaren Anteil zum Projekt bei und jedes dieser Elemente arbeitet unabhängig von den anderen Elementen
- Sequentiell: Der Output des einen Elementes wird zum Input des nächsten Elementes
- Wechselseitig: Der Output eines jeden Elementes wird zum Input anderer Elemente

Besonders der letzte Wechselwirkungstyp intensiviert die Komplexität und führt zu Rückkopplungen zwischen den Elementen. Somit kann festgehalten werden, dass die Komplexität eines Projektes deutlich mit dem Typ der Wechselbeziehungen zu- oder abnimmt.^[156]

Komplexität in Projekten, wie sie oben definiert wurde, entsteht auch durch Mehrdeutigkeit und einen Mangel an Struktur. Mehrdeutigkeit umfasst in diesem Sinne Unordnung, Ablehnung und einen Mangel an Verständnis.^[157] Allgemein lässt sich das Phänomen Komplexität von Projekten in die Gruppe der Risikofaktoren einordnen.^[158] Unter Risikofaktoren werden die Umstände oder Bedingungen verstanden, die eine erfolgreiche Projektfertigstellung gefährden.^[159]

Die Komplexität der besonderen Projektform ISDP wird von der großen Anzahl an Fehlschlägen untermauert, die durch viele Studien und Berichte in verschiedensten Organisationen und Branchen nachgewiesen werden konnte.^[160] Der Grund für die Komplexität von ISDP liegt in der Tatsache, dass diese Projekte nicht nur verschiedene Technologien, sondern auch verschiedene Geschäftsprozesse umfassen. Zum einen müssen alte Systeme und Technologien mit neuen kombiniert und in Einklang gebracht werden und zum anderen ändern sich die Geschäftsprozesse permanent, so dass sich damit auch die Anforderungen an das IS ständig ändern.^[161]

Aber nicht nur das Wechselspiel zwischen den beteiligten Systemen, wie Technologie und Organisation, sondern auch die Komplexität der einzelnen Systeme an sich trägt zur gesamten Komplexität eines ISDP bei. So ist die Komplexität ein integraler Bestandteil von Software im allgemeinen, da ihre Form einzigartig, unsichtbar und nicht zu veranschaulichen ist.^[162] Hinzu kommt, dass Software und damit auch die Komplexität derselbigen einem ständigen Wandel unterliegt.^[163]

Die Auswirkungen von Komplexität sind vielschichtig. Wie oben bereits geschildert, tragen komplexe Projektelemente zu einer Intensivierung der Komplexität des gesamten Projektes bei. So stellen die beteiligten Personen und die Vereinbarkeit der Ziele der einzelnen Projektelemente eine nicht unerhebliche Quelle an Komplexität dar.^[164] Diese Komplexität überträgt sich auf das gesamte Projekt, so dass die Zielermittlung von großen Projekten deutlich erschwert wird und die Auswahl der Projektmitglieder, sowie die Zielvorgaben Zeit, Kosten und Qualität davon wesentlich beeinflusst werden.^[165]

2.3.4 Rahmenwerk von Xia&Lee

Zwar ist Komplexität eine Eigenschaft, die schon von Natur aus in ISDP zu finden ist^[166], jedoch stellt die zunehmende Komplexität von ISDP Organisationen aller Art vor immer neue Schwierigkeiten.^[167] Deshalb ist es zur weiteren Erforschung unabdingbar, dass geeignete Messgrößen definiert werden, um das Phänomen Komplexität empirisch untersuchen zu können.^[168]

Einen Vorschlag für ein Rahmenwerk mit solchen Messgrößen haben Xia&Lee in Xia; Lee (2005) vorgeschlagen. Das Rahmenwerk wurde durch Literaturrecherche, Interviews, Gruppendiskussionen, Sortierungen und zwei Pilottests verfeinert und anschließend durch Umfragen bestätigt.^[169] Das Rahmenwerk gliedert sich in zwei Dimensionen. Die erste unterscheidet zwischen dem strukturellen Aufbau und den dynamischen Aspekten, die in einem ISDP vorkommen.^[170] Die zweite Dimension unterscheidet, ob organisatorische oder technische Komponenten des Projektes von der Komplexität betroffen sind.^[171]

2.3.4.1 Dimensionen

Unter struktureller Komplexität verstehen Xia&Lee Mannigfaltigkeit (Varietät, engl. variety), Vielfachheit (alternativ Multiplizität, engl. multiplicity) und Ausdifferenzierung (engl. differentiation) der Projektelemente, sowie deren gegenseitige Abhängigkeit (engl. interdependency), Wechselbeziehung (engl. interaction), Koordination (engl. coordination) und Verflechtung (engl. integration).^[172] Somit hängt strukturelle Komplexität nicht nur von der Anzahl der Projektelemente sondern auch von den Beziehungen zwischen den Elementen ab.^[173] Xia&Lee schränken diese vielfältigen Definitionen später ein und reduzieren strukturelle Komplexität auf Vielfachheit und Abhängigkeit.^[174]

[...]

---

^[1] Vgl.MacDonald (1999),S.B14.

^[2] Vgl.Foust (2000),S.97.

^[3] Vgl.Foust (2000),S.97.

^[4] Vgl.Nash (2000),S.35.

^[5] Vgl.Scott, Vessey (2002),S.74;Nash (2000),S.35.

^[6] Vgl.Scott, Vessey (2002),S.74;Nash (2000),S.35.

^[7] Vgl.McManus, Wood-Harper (2007),S.38.

^[8] Vgl.Wastell, Newman (1996),S.284.

^[9] Vgl.Wastell, Newman (1996),S.284.

^[10] Vgl.Wastell, Newman (1996),S.284.

^[11] Vgl.BCS (2004),S.4.

^[12] Vgl.Denning (2004),S.18.

^[13] Vgl.Brooks (1987),S.11.

^[14] Vgl.Brooks (1987),S.11.

^[15] Vgl.Xia, Lee (2005),S.46.

^[16] Vgl.BCS (2004),S.12.

^[17] Vgl.Davis, Venkatesh (2004),S.31.

^[18] Vgl.BCS (2004),S.4.

^[19] Vgl.Jaccuci, Hanseth, Lyytinen (2006),S.6;Brooks (1987),S.11f.

^[20] Vgl.Jaccuci, Hanseth, Lyytinen (2006),S.6

^[21] Vgl.Heinrich, Burgholzer (1991),S.8.

^[22] Vgl.Hansen, Neumann (2002),S.132.

^[23] Vgl.Teubner (1999),S.20.

^[24] Vgl.Heinrich, Burgholzer (1991),S.8ff;Heinrich, Burgholzer (1990),S.203f.

^[25] Vgl.Bacon, Fitzgerald (2001),S.55.

^[26] Vgl.Cotterman, Senn (1992),S.1ff.

^[27] Vgl.imFolgendenBacon, Fitzgerald (2001),S.55.

^[28] Vgl.Bacon, Fitzgerald (2001),S.55.

^[29] Vgl.Laroche (1995),S.63; Langley u. a. (1995),S.264ff; Johnson (1987),S.26f; Mintzberg (1975),S.51f.

^[30] Vgl.Nonaka, Takeuchi (1995),S.96;English (1999),S.4-12; Redman (1996),S4-13.

^[31] Vgl.imFolgendenLaudon, Laudon (2005),S.43-53.

^[32] Laudon, Laudon (2005);Stahlknecht, Hasenkamp (2005);Hansen, Neumann (2002).

^[33] Vgl.imFolgendenLaudon, Laudon (2005),S.56f.

^[34] Vgl.imFolgendenGlaser (2005),S.68ff.

^[35] Vgl.imFolgendenJenny (2001),S.3f.

^[36] Vgl.Böhm, Fuchs, Pacher (1993),S.1.

^[37] Vgl.Böhm, Fuchs, Pacher (1993),S.1.

^[38] Vgl.imFolgendenSchmidt (1985), S. 234f; Jenny (2001),S.6-11.

^[39] Vgl.Krcmar (2000),S.20;Heinrich, Burgholzer (1991),S.8.

^[40] Vgl.Heinrich, Burgholzer (1991),S.8f.

^[41] Vgl.Heinrich, Burgholzer (1991),S.8.

^[42] Vgl.Krcmar (2000),S.20.

^[43] Vgl.Teubner (1999),S.27.

^[44] Vgl.Teubner (1999),S.26.

^[45] Vgl.Teubner (1999),S.26;Laudon, Laudon (2005),S.15.

^[46] Vgl.Teubner (1999),S.22.

^[47] Vgl.Teubner (2004),S.3.

^[48] Vgl.Duncan (1995),S.41.

^[49] Vgl.Niederman, Brancheau, Wetherbe (1991),S.479.

^[50] Vgl.Laudon, Laudon (2005),S.30.

^[51] Vgl.Teubner (1999),S.28.

^[52] Vgl.Teubner (1999),S.28.

^[53] Vgl.Teubner (1999),S.28.

^[54] Laudon, Laudon (2005),S.77.

^[55] Vgl.Laudon, Laudon (2005),S.78.

^[56] Vgl.Holten (2003),S.33.

^[57] Vgl.Holten (2003),S.33.

^[58] Vgl.Holten (2003),S.33.

^[59] Vgl.imFolgendenLinke, Nussbaumer, Portmann (2001),S.350.

^[60] Vgl.Holten (2003).

^[61] Vgl.Holten (2003),S.34.

^[62] Vgl.Kamlah, Lorenzen (1996),S.54.

^[63] Vgl.Kamlah, Lorenzen (1996),S.57f.

^[64] Vgl.Kamlah, Lorenzen (1996),S.57.

^[65] Vgl.Kamlah, Lorenzen (1996),S.58.

^[66] Vgl.Kamlah, Lorenzen (1996),S.29.

^[67] Vgl.Kamlah, Lorenzen (1996),S.86.

^[68] Vgl.Holten (2003),S.58f;Kamlah, Lorenzen (1996),S.60.

^[69] Vgl.Holten (2003),S.58.

^[70] Vgl.Holten (2003),S.48.

^[71] Vgl.Holten (2003),S.59.

^[72] Vgl.Holten (2003),S.59.

^[73] Vgl.Holten (2003),S.65.

^[74] Vgl.Holten (2003).

^[75] Vgl.Holten (2003),S.76.

^[76] Vgl.Holten (2003),S.78.

^[77] Vgl.Holten (2003),S.80.

^[78] Vgl.imFolgendenAvgerou (2000),S.238.

^[79] Vgl.Bacon, Fitzgerald (2001),S.55.

^[80] Vgl.ImFolgendenJenny (2001),S.25-35; Böhm, Fuchs, Pacher (1993),S.63-69.

^[81] Vgl.Österle, Brenner, Hilbers (1991),S.206f.

^[82] Vgl.Österle, Brenner, Hilbers (1991),S.223;Österle, Brenner, Hilbers (1991),S.235f.

^[83] Vgl.Jenny (2001),S.40f.

^[84] Vgl.imFolgendenJenny (2001),S.464ff.

^[85] Vgl.Österle, Brenner, Hilbers (1991),S.216f.

^[86] Vgl.Österle, Brenner, Hilbers (1991),S.214f.

^[87] Vgl.imFolgendenJenny (2001),S.469ff.

^[88] Vgl.Österle, Brenner, Hilbers (1991),S.224-227;PMI (2000),S.112ff;Jenny (2001),S.472f.

^[89] Vgl.Jenny (2001)S.473ff.

^[90] Vgl.PMI (2000),S.33;PMI (2000),S.36;Jenny (2001),S.477.

^[91] Vgl.PMI (2000),S.33ff;Jenny (2001),S.477ff.

^[92] Vgl.Jenny (2001),S.480.

^[93] Vgl.Jenny (2001),S.481.

^[94] Vgl.Österle, Brenner, Hilbers (1991),S.239f; Jenny (2001),S.489.

^[95] Vgl.Jenny (2001),S.490.

^[96] Vgl.Jenny (2001),S.490.

^[97] Vgl.PMI (2000),S.102;Jenny (2001),S.490.

^[98] Vgl.imFolgendenJenny (2001),S.494ff; PMI (2000),S.125f.

^[99] Vgl.IEEE (2004).

^[100] Vgl.PMI (2000),S.6.

^[101] Vgl.Jenny (2001),S.62.

^[102] Vgl.Jenny (2001),S.98.

^[103] Vgl.Jenny (2001),S.99.

^[104] Vgl.Jenny (2001),S.97.

^[105] Vgl.Jenny (2001),S.199.

^[106] Vgl.Jenny (2001),S.53.

^[107] Vgl.Jenny (2001),S.82.

^[108] Vgl.Jenny (2001),S.82f.

^[109] Vgl.imFolgendenCadle, Yeates (2004),S.77ff.

^[110] Vgl.imFolgendenCadle, Yeates (2004),S.83f.

^[111] Vgl.Avison, Fitzgerald (2003),S.424.

^[112] Vgl.Jacobson, Booch, Rumbaugh (1999),S.3-13.

^[113] Vgl.Avison, Fitzgerald (2003),S.426.

^[114] Vgl.Avison, Fitzgerald (2003),S.428f; Kruchten (2000),S.139f .

^[115] Vgl.Kruchten (2000),S.155f.

^[116] Vgl.Kruchten (2000),S.171f.

^[117] Vgl.Kruchten (2000),S.183f.

^[118] Vgl.Kruchten (2000),S.193f.

^[119] Vgl.Avison, Fitzgerald (2003),S.429.

^[120] Vgl.Kruchten (2000),S.207f.

^[121] Vgl.Kruchten (2000),S.113f.

^[122] Vgl.Kruchten (2000),S.221f.

^[123] Vgl.imFolgendenInterviews.

^[124] Vgl. James (2002),S.186.

^[125] Vgl.James (2002),S.186.

^[126] Vgl.Verville, Halington (2003);James (2002);Verville, Bernadas, Halington (2005); Wyde, Pack (1997).

^[127] Vgl.Brockhaus-Enzyklopädie (2006),Band15,S.382

^[128] Vgl.Schlindwein, Ison (2004),S.28.

^[129] Vgl.imFolgendenEdmonds (1999b),S.3-6.

^[130] Vgl.imFolgendenEdmonds (1999b),S.3f.

^[131] Vgl.Edmonds (1999b),S.4.

^[132] Vgl.Ashby (1956),S.126.

^[133] Vgl.Ashby (1956),S.125.

^[134] Vgl.Edmonds (1999b),S.4-8.

^[135] Vgl.Edmonds (1999b)S.5f.

^[136] Vgl.imFolgendenEdmonds (1999b),S.7f.

^[137] Der Aufbau einer Turingmaschine besitzt Ähnlichkeit mit einem Kassettenrekorder. Sie besitzt ein Band, welches in diskrete Sektionen unterteilt ist und einen Schreib-und Lesekopf. In jeder Sektion des Bandes befindet sich entweder eine Eins oder eine Null, die von der Maschine gelesen wird. Für jede gelesene Zahl besitzt die Maschine eine Tabelle mit weiteren Befehlen. In Abhängigkeit des aktuellen Zustandes der Maschine und der Zahl auf dem Band, wird nun entweder eine Eins oder eine Null auf das Band geschrieben oder der Schreib-und Lesekopf bewegt sich nach rechts oder nach links. Vgl. Eliasmith (2002),S.2.

^[138] Vgl.Kauffman (1993),S.67.

^[139] Vgl.Yates (1978),S.R201.

^[140] Vgl.Desai (2005),S.34.

^[141] Vgl.Desai (2005),S.34.

^[142] Vgl.imFolgendenManson (2001),S.405f.

^[143] Vgl.Manson (2001),S.406.

^[144] Vgl.imFolgendenManson (2001),S.406.

^[145] Vgl.imFolgendenManson (2001),S.405ff.

^[146] Vgl.Feigenbaum (1980),S.25f.

^[147] Vgl.Prigogine, Stengers (1984),S.207.

^[148] Vgl.Manson (2001),S.405.

^[149] Vgl.im FolgendenManson (2001),S.409f.

^[150] Vgl.Constanza, Wainger, Folke (1993),S.550f.

^[151] Vgl.Baas, Emmeche (1997),S.4;Lansing, Kremer (1993),S.111f.

^[152] Vgl.Schieve, Allen (1982),S.IXf.

^[153] Vgl.Scheinkman, Woodford (1994),S.417.

^[154] Vgl.Baccarini (1996),S.201f.

^[155] Vgl.Thomson (1967),S.15ff.

^[156] Vgl.Williams (1999),S.270.

^[157] Vgl.Daft, Lengel, Trevino (1987),S.356.

^[158] Vgl.Lee, Xia (2002),S.2.

^[159] Vgl.Schmidt u. a. (2001),S.7.

^[160] Vgl.Xia, Lee (2005),S.46.

^[161] Vgl.Lee, Xia (2002),S.1f.

^[162] Vgl.Brooks (1987),S.11.

^[163] Vgl.Xia, Lee (2005),S.47.

^[164] Vgl.Williams (1999),S.270.

^[165] Vgl.Baccarini (1996),S.201.

^[166] Vgl.Xia, Lee (2005),S.46.

^[167] Vgl.Benamati, Lederer (2001),S.83;Murray (2000),S.30.

^[168] Vgl.Xia, Lee (2005),S.48.

^[169] Vgl.Xia, Lee (2005),S.47.

^[170] Vgl.Xia, Lee (2005),S.54.

^[171] Vgl.Xia, Lee (2005),S.54.

^[172] Vgl.Xia, Lee (2005),S.54; Varietät im, Sinne von: Ribbers, Schoo (2002),S.46; Vielfachheit im, Sinne von: Campbell (1988),S.42; Tait, Vessey (1988),S.98; Williams (1999),S.270; Wozniak (1993)zit.n.Xia, Lee (2005),S.54; Ausdifferenzierung im Sinne von: Baccarini (1996),S.201f; Abhängigkeit im, Sinne von: Baccarini (1996),S.202; Barki, Rivard, Talbot (2001),S.45; Campbell (1988),S.43; Tatikonda, Rosenthal (2000),S.78; Williams (1999),S.269; Wechselbeziehung im, Sinne von: Pich, Loch, Meyer (2002),S.1013;Tait, Vessey (1988),S.98; Koordination im Sinne von: Wozniak (1993)zit.n.Xia, Lee (2005),S.54; Verflechtung im Sinne von: Ribbers, Schoo (2002),S.46.

^[173] Vgl.Lee, Xia (2002),S.3;Williams (1999),S.271.

^[174] Vgl.Xia, Lee (2005),S.55f.