Quelltext der Seite Modularität

{{Weiterleitungshinweis|Modularisierung|Das Prinzip in der Programmierung ist unter [[modulare Programmierung]] beschrieben.}}
'''Modularität''' (auch '''Baustein-''' oder '''Baukastenprinzip''') ist die Aufteilung eines Ganzen in Teile, die als Module, Komponenten, Bauelemente, [[Baugruppe]]n oder Bausteine bezeichnet werden. Bei geeigneter Form und Funktion können sie zusammengefügt werden oder über entsprechende Schnittstellen interagieren.

Bei einem ''modularisierten Aufbau'' werden Systeme aus Bauteilen entlang definierter Stellen (bei Programmen [[Schnittstelle]]n) zusammengesetzt. Die gegenteilige Bauweise nennt man einen ''integralen Aufbau'', oder auch ''[[Monolith|monolithisch]]'' ([[Griechische Sprache|griechisch]] ''monólithos'', „der Einstein“). Dies kann sich sowohl auf reale Objekte, als auch auf Immaterielles, wie beispielsweise eine Ausbildung beziehen.

Als Anwendungsparadigmen für Modularität lassen sich u. a. unterscheiden: Modularität in der Entwicklung (z.&nbsp;B. in Anlagenbau, Softwarearchitektur oder Unternehmensorganisation), Modularität in der Produktion ([[Mass Customization]], z.&nbsp;B. in Automobilbau, Computer-Fertigung und Architektur) sowie Modularität im Gebrauch (“[[Plug and Play]]”).<ref name="Osterloh">Margit Osterloh: ''{{Webarchiv |url=http://www.uzh.ch/iou/orga/ssl-dir/wiki/uploads/Main/V06_OrgaIIa.pdf |text=Das Management von Strukturen und Prozessen |wayback=20160304045200 |archiv-bot=2019-05-02 03:00:38 InternetArchiveBot}}''. IOU – Institut für Organisation und Unternehmenstheorien, Universität Zürich, 2. Mai 2006.</ref>

== Wissenschaftlicher Hintergrund ==

Einige Forscher geben eine Definition von der Architektur von allgemeinen [[System]]en,<ref name="Crawley">{{Internetquelle |autor=Edward Crawley, Olivier de Weck, Steven Eppinger, Christopher Magee, Joel Moses, Warren Seering, Joel Schindall, David Wallace, Daniel Whitney |url=https://esd.mit.edu/symposium/pdfs/monograph/architecture-b.pdf |titel=
THE INFLUENCE OF ARCHITECTURE IN ENGINEERING SYSTEMS |titelerg=Monograph of the MIT ESD Architecture Committee |werk=Engineering Systems Symposium Proceedings |datum=2004-03 |format=PDF |sprache=en |abruf=2016-04-29}}</ref><ref name="S&M">{{Literatur |Autor=Ron Sanchez, Joseph T. Mahoney |Titel=Modularity, flexibility, and knowledge management in product and organization design |Sammelwerk=Strategic Management Journal |Band=17 |Nummer=2 |Datum=1996 |Seiten=63–76 |DOI=10.1002/smj.4250171107}}</ref> während andere sich dabei auf die Architektur von [[Produkt (Wirtschaft)|Produkten]] beziehen.<ref name="Ulrich1995">{{Literatur |Autor=Karl Ulrich |Titel=The role of product architecture in the manufacturing firm |Sammelwerk=Research Policy |Band=24 |Nummer=3 |Datum=1995 |Seiten=419–440 |DOI=10.1016/0048-7333(94)00775-3}}</ref> Den verschiedenen Definitionen liegt dennoch der gleiche Gedanke zugrunde, dass Architektur den strukturellen Aufbau eines Systems beschreibt und somit als ein [[Entwerfen|Entwurf]] anzusehen ist, welcher die [[Bestandteil]]e eines Systems, deren jeweilige Funktionen und die [[Schnittstelle]]n zwischen diesen definiert:<ref name="B&C1997">{{Literatur |Autor=C. Y. Baldwin, K. B. Clark |Titel=Managing in an Age of Modularity |Sammelwerk=Harvard Business Review |Band=75 |Nummer=5 |Datum=1997 |Seiten=84–93}}</ref>

* Crawley u. a. (2004) identifizieren die Architektur als Schlüsselelement für die [[Planung]], den Betrieb und das Verhalten [[Komplexes System|komplexer Systeme]]. Dabei ist die Architektur eine abstrakte Beschreibung eines Systems, seiner Elemente und der Beziehungen zwischen diesen. Die Architektur ist in der Lage die Funktionen und [[Eigenschaft]]en von Systemen zu beeinflussen.<ref name="Crawley" />

* Sanchez und Mahoney (1996) beschreiben die Architektur eines komplexen Systems, ob nun ein Produkt oder aber eine organisationale Struktur, als ein Konstrukt aus mehreren miteinander interagierenden Teilen, welche zu einem gewissen Grad voneinander abhängig sind. In einer weiteren Definition der Architektur von Produkten erklären Sanchez und Mahoney, dass eine Komponente innerhalb einer Produktdesigns eine Funktion innerhalb eines Systems, von miteinander interagierenden Komponenten, ausübt und deren gemeinsame Funktionen das Produkt abbildet. Die Beziehungen zwischen den Komponenten und der sie verbindenden Schnittstellen bildet die Produktarchitektur.<ref name="S&M" />

* Architektur ist das Muster, nach welchem Funktionen physikalischen Objekten zugeordnet werden und wie diese miteinander interagieren. Auf dieser Definition basierend erklärt Ulrich (1995) die Architektur eines Produktes weiter als Anordnung funktionaler Elemente, die Zuordnung dieser zu physikalischen Komponenten sowie die Festlegung der Schnittstellen zwischen diesen. Dabei bezeichnet Ulrich funktionale Elemente als einzelne Funktionen, welche durch das Produkt erfüllt werden. Die Anordnung dieser stellt damit eine funktionale Struktur dar. Ein physikalisches Produkt besteht dabei aus einer oder mehrerer Komponenten, welche die funktionalen Elemente des Produktes ausüben. Hierbei können eine oder mehrere dieser Komponenten auch einem oder mehreren funktionalen Elementen zugeordnet werden und diese ausüben. Die gegenseitig aufeinander einwirkenden Komponenten sind dabei mit Schnittstellen verbunden, welche die [[Interaktion]]en zwischen ihnen koordinieren.<ref name="Ulrich1995" />

Ist ein funktionales Element genau einer Komponente des Systems zugeordnet, spricht man von einer eher modularen Struktur. Wird ein funktionales Element von mehreren Komponenten ausgeübt, spricht man von einer eher integralen Struktur. Aus diesem Grund können sich Systeme, welche die gleichen Aufgaben erfüllen, in ihrer Architektur grundlegend unterscheiden.<ref name="S&M" /><ref name="Ulrich1995" /><ref name="MacCormack2006">{{Literatur |Autor=Alan MacCormack, John Rusnak, Carliss Y. Baldwin |Titel=Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code |Sammelwerk=Management Science |Band=52 |Nummer=7 |Datum=2006 |Seiten=1015-1030 |DOI=10.1287/mnsc.1060.0552}}</ref>

Die Zustände komplett modularer oder integraler Produkte sind keine klar bestimmten Zustände und stellen in der Realität eher nicht aufzufindende Fälle dar. Dennoch lassen sich Systemenarchitekturen vom Grad der beiden Zustände differenzieren, befinden sich auf einer, in ihren Grenzen, nicht klar festgelegten Skala zwischen diesen beiden Extremfällen und können sich jeweils einem Zustand annähern oder aber auch davon entfernen. So sagt man Systemen, welche man in ihre Komponenten zerteilen, umgestalten und wieder zusammenfügenkann, ohne dass sie dabei einen Verlust von Funktionalität erleiden, einen hohen Grad an Modularität zu.<ref name="B&C2006">{{Literatur |Autor=Carliss Y. Baldwin, Kim B. Clark |Titel=The Architecture of Participation: Does Code Architecture Mitigate Free Riding in the Open Source Development Model? |Sammelwerk=Management Science |Band=52 |Nummer=7 |Datum=2006 |Seiten=1116-1127 |DOI=10.1287/mnsc.1060.0546}}</ref><ref name="C&C">{{Literatur |Autor=Anna Cabigiosu, Arnaldo Camuffo |Titel=Beyond the “Mirroring” Hypothesis: Product Modularity and Interorganizational Relations in the Air Conditioning Industry |Sammelwerk=Organization Science |Band=23 |Nummer=3 |Datum=2012 |Seiten=686-703 |DOI=10.1287/orsc.1110.0655}}</ref><ref name="E&L">{{Literatur |Autor=Sendil K. Ethiraj, Daniel Levinthal |Titel=Modularity and Innovation in Complex Systems |Sammelwerk=Management Science |Band=50 |Nummer=2 |Datum=2004 |Seiten=159-173 |DOI=10.1287/mnsc.1030.0145}}</ref><ref name="Sosa">{{Literatur |Autor=Manuel E. Sosa, Steven D. Eppinger, Craig M. Rowles |Titel=The Misalignment of Product Architecture and Organizational Structure in Complex Product Development |Sammelwerk=Management Science |Band=50 |Nummer=12 |Datum=2004 |Seiten=1674-1689 |DOI=10.1287/mnsc.1040.0289}}</ref><ref name="Hoetker">{{Literatur |Autor=Glenn Hoetker |Titel=Do Modular Products Lead to Modular Organizations? |Sammelwerk=Strategic Management Journal |Band=27 |Nummer=6 |Datum=2006 |Seiten=501-518 |DOI=10.1002/smj.528}}</ref>

Die kleinste vornehmbare Änderungen an einem System ist eine Änderungen einer der Komponenten. Die Systemarchitektur bestimmt dabei, welche funktionalen Elemente durch eine Änderung beeinflusst werden und welche weiteren Komponenten davon betroffen sind. Darum steht die Art der Architektur eines Systems in direktem Zusammenhang mit dem Grad seiner Komplexität und der Möglichkeit Veränderungen in diesem durchzuführen.<ref name="Ulrich1995" />

[[George Stigler]] beobachtete, dass viele Industrien durch ihre kleine Größe mit einer vertikal integrierten Struktur begannen und im Laufe ihres Wachstums die Anzahl an spezialisierten Unternehmen zunahm.<ref>{{Literatur |Autor=George J. Stigler |Titel=The Division of Labor is Limited by the Extent of the Market |Sammelwerk=Journal of Political Economy |Band=59 |Nummer=3 |Datum=1951 |Seiten=185-193}}</ref> Diese Beobachtung, dass es bei wissensintensiven Prozessen zu einem industrieübergreifenden Wandel zu immer höher spezialisierten Unternehmen und damit auch einer Zunahme an verteilten oder auch unternehmensübergreifenden Entwicklungen neuer komplexer Systeme kommt, wurde später von weiteren Forschern bestätigt.<ref>{{Literatur |Autor=Sebastian K. Fixson, Jin-Kyu Park |Titel=The power of integrality: Linkages between product architecture, innovation, and industry structure |Sammelwerk=Research Policy |Band=37 |Nummer=8 |Datum=2008 |Seiten=1296–1316 |DOI=10.1016/j.respol.2008.04.026}}</ref>

So wurde dieser Wandel in der [[Festplattenlaufwerk|Festplatten]]-,<ref name="Christensen">{{Literatur |Autor=Clayton M. Christensen, Matt Verlinden, George Westerman |Titel=Disruption, disintegration and the dissipation of differentiability |Sammelwerk=Industrial and Corporate Change |Band=11 |Nummer=5 |Datum=2002 |Seiten=955-993 |DOI=10.1093/icc/11.5.955}}</ref> [[Computer]]-,<ref name="Christensen" /><ref>{{Literatur |Autor=Ron Adner, Daniel Levinthal |Titel=Demand Heterogeneity and Technology Evolution: Implications for Product and Process Innovation |Sammelwerk=Management Science |Band=47 |Nummer=5 |Datum=2001 |Seiten=611-628 |DOI=10.1287/mnsc.47.5.611.10482}}</ref><ref name="Langlois">{{Literatur |Autor=Richard N. Langlois, Paul L. Robertson |Titel=Networks and innovation in a modular system: Lessons from the microcomputer and stereo component industries |Sammelwerk=Research Policy |Band=21 |Nummer=4 |Datum=1992 |Seiten=297-313 |DOI=10.1016/0048-7333(92)90030-8}}</ref> [[Mikroprozessor]]-,<ref name="Christensen" /><ref>{{Literatur |Autor=Allan Afuah |Titel=Dynamic Boundaries of the Firm: Are Firms Better off Being Vertically Integrated in the Face of a Technological Change? |Sammelwerk=The Academy of Management Journal |Band=44 |Nummer=6 |Datum=2001 |Seiten=1211-1228 |DOI=10.2307/3069397}}</ref> [[High Fidelity|High-Fidelity]]-,<ref name="Langlois" /> [[Fahrrad]]-<ref>{{Literatur |Autor=Peter Galvin, Andre Morkel |Titel=The effect of product modularity on industry structure: The case of the world bicycle industry |Sammelwerk=Industry and Innovation |Band=8 |Nummer=1 |Datum=2001 |Seiten=31-47 |DOI=10.1080/13662710120034392}}</ref> und [[Automobilindustrie]]<ref>{{Literatur |Autor=Nicholas Argyres, Lyda Bigelow |Titel=Innovation, Modularity, and Vertical Deintegration: Evidence from the Early U.S. Auto Industry |Sammelwerk=Organization Science |Band=21 |Nummer=4 |Datum=2010 |Seiten=842-853 |DOI=10.1287/orsc.1090.0493}}</ref> nachgewiesen. Die effiziente Umsetzung dieses Trends wird erst durch modulare Produktarchitekturen ermöglicht.

== Funktionsprinzipien ==
[[Datei:Network Community Structure.svg|mini|Skizze eines kleinen Nachbarschaftsnetzwerks mit drei voneinander relativ unabhängigen Komponenten (oder Modulen). Die wenigen Verbindungen der Module untereinander repräsentieren ihre Schnittstellen.]]

Das Konzept der Modularität wurde in der Forschung mit unterschiedlichen zugrundeliegenden Definitionen behandelt. Diesen Definitionen unterliegt generell das Verständnis, dass Modularität den Zustand eines Systems beschreibt in welchem die Abhängigkeiten zwischen den einzelnen Komponenten niedrig gehalten und ihre Interaktionen miteinander über standardisierte Schnittstellen koordiniert werden. Einzelne bis alle Komponenten des Systems sind dabei durch andere Komponenten austauschbar ohne die Funktionsfähigkeit des Gesamten zu gefährden.<ref name="Ulrich1995" /><ref name="Langlois" /><ref>{{Literatur |Autor=Melissa A. Schilling |Titel=Toward a General Modular Systems Theory and Its Application to Interfirm Product Modularity |Sammelwerk=The Academy of Management Review |Band=25 |Nummer=2 |Datum=2000 |Seiten=312-334 |DOI=10.5465/AMR.2000.3312918}}</ref><ref>{{Literatur |Autor=Herbert A. Simon |Titel=The Architecture of Complexity |Sammelwerk=Proceedings of the American Philosophical Society |Band=106 |Nummer=6 |Datum=1962 |Seiten=467-482}}</ref>

Als Folge eines solchen Systemzustandes können die einzelnen Module weitgehend unabhängig voneinander operieren oder bei einem Produkt voneinander entwickelt und hergestellt werden.<ref name="S&M" /><ref name="Langlois2002">{{Literatur |Autor=Richard N. Langlois |Titel=Modularity in technology and organization |Sammelwerk=Journal of Economic Behavior & Organization |Band=49 |Nummer=1 |Datum=2002 |Seiten=19–37 |DOI=10.1016/S0167-2681(02)00056-2}}</ref><ref name="Terwiesch">{{Literatur |Autor=Christian Terwiesch, Christoph H. Loch, Arnoud De Meyer |Titel=Exchanging Preliminary Information in Concurrent Engineering: Alternative Coordination Strategies |Sammelwerk=Organization Science |Band=13 |Nummer=4 |Datum=2002 |Seiten=402-419 |DOI=10.1287/orsc.13.4.402.2948}}</ref><ref>{{Literatur |Autor=Fabrizio Salvador, Cipriano Forza, Manus Rungtusanatham |Titel=Modularity, product variety, production volume, and component sourcing: theorizing beyond generic prescriptions |Sammelwerk=Journal of Operations Management |Band=20 |Nummer=5 |Datum=2002 |Seiten=549–575 |DOI=10.1016/S0272-6963(02)00027-X}}</ref>

Einzelne Komponenten lassen sich unterschiedlich zu einem Ganzen kombinieren, wenn sie wie [[Baukasten|Spielbausteine]] ausgeführt sind – das beschreibt das sprachliche Bild, das Gegenteil wäre einem [[Puzzle]] vergleichbar, bei dem jede Komponente nur genau einen möglichen Platz hat, und das System nur als ein ganzer Block (monolithisch) funktioniert.

Ein großer Vorteil ist, dass man alte Module leicht gegen neue Module austauschen oder neue Module zum Ganzen hinzufügen kann. Dafür brauchen Module klare [[Schnittstelle]]n – möglichst [[Normung#Form und Inhalt einer Norm|genormt]], um Probleme der [[Kompatibilität (Technik)|Kompatibilität]] (des „Zusammenpassens“) gering zu halten.

Änderungen innerhalb von Modulen sollten sich nicht auf andere Module auswirken. Dieses Prinzip nennt man ''lokale Stetigkeit bei Änderungen''. Um Änderungen möglichst problemlos durchführen zu können, sollte die Anzahl der Schnittstellen möglichst klein sein. Treten Fehler in Modulen auf, dürfen diese Fehler andere Module nicht in Mitleidenschaft ziehen („lokaler Schutz bei Ausnahmefehlern“). Diese Prinzipien betreffen beispielsweise die Modularität von Softwareprojekten, sind jedoch auch auf andere Bereiche anwendbar. Hierdurch ist es auch möglich, die statistische [[Haltbarkeit (Technik)|Lebensdauer]] von Modulen untereinander zu entkoppeln und z.&nbsp;B. Innovationen gezielt und störungsfrei in bestehende Systeme einzubringen.

Module setzen das [[Black Box (Systemtheorie)|Black-Box-Modell]] um. Informationen sind nur über explizite Schnittstellen zugänglich.

== Herausforderungen ==
Immer mehr Unternehmen strukturieren ihre Produkte in Baukästen, um individuell konfigurierbare Endprodukte erzeugen zu können, ohne auf baureihenübergreifende Skaleneffekte verzichten zu müssen. Aufgrund entscheidender Unterschiede zwischen Baukastensystem und der klassischen Produktentwicklung stehen Unternehmen bei der Baukastengestaltung vor der Herausforderung erhöhter Entwicklungsaufwände, da sich Module nicht mehr auf einzelne Produkte und deren Produktionsprozesse beziehen, sondern eine ungleich höhere Produktvielfalt ermöglichen. Die unterschiedlichen Kundenanforderungen müssen durch standardisierte Bausteine und individuelle Anpasselemente flexibel über den Baukasten realisierbar sein. Organisatorisch stehen Unternehmen vor der Herausforderung, den übergreifenden Einsatz von Baugruppen und Modulen innerhalb des Baukastens mit der notwendigen Akzeptanz und Verständnis bei den Mitarbeitern zu etablieren.

== Anforderungen der Baukastengestaltung ==
Das Schaffen von Akzeptanz und Verständnis für die branchenübergreifende Anwendbarkeit und alle an der Wertschöpfung beteiligten Bereiche des Baukastenentwicklungsprozesses ist von großer Bedeutung. Der Fokus liegt nicht alleine auf dem Produkt, sondern auch auf der Produktion, der Montage, dem Markt und weiteren Feldern der Wertschöpfungskette, die in den Entwicklungsprozess eingebunden werden sollen, sodass alle Beteiligten zu jedem Zeitpunkt den Überblick über den Entwicklungsstand behalten und sich einbringen können.

== Vorteile und Nutzen ==
[[Datei:2010-04-07 Unimog at Arthur Ibbetts machinery dealership.jpg|mini|[[Unimog 405]] mit [[Heckenschere]] von [[MULAG Fahrzeugwerk|MULAG]] als modulares [[Traktor#Anbaugeräte|Anbaugerät]]. Durch verschiedene kompatible Module die zur Verfügung stehen und angebracht, entfernt, gewechselt oder anders gruppiert werden können, lässt sich das Fahrzeug-System an verschiedene Bedingungen anpassen]]

Durch die Modularität von komplexen Systemen lässt sich deren Verständlichkeit für den Menschen erhöhen. Für den Hersteller bzw. das Unternehmen, für den Service wie auch für den Konsumenten bzw. Kunden kann ein Baukastenprinzip Vorteile bringen, besonders wenn unterschiedliche Unternehmen am Markt als Anbieter von weitgehend [[standard]]isierten Einzelkomponenten bzw. Geschäftsprozessen miteinander konkurrieren. Mögliche Vorteile sind:
* niedrigere [[Produktentwicklung|Entwicklungs]]- bzw. [[Geschäftsprozess]]kosten: Modularisierung reduziert Koordinations- und Kommunikationskosten und ermöglicht [[Outsourcing]] und [[Benchmark]]ing.
* Flexibilität in der Produkt- bzw. Organisationsentwicklung: schnellere [[Produktlebenszyklus|Produktzyklen]] und höhere [[Anpassungsfähigkeit]], wenn verschiedene kompatible Module zur Verfügung stehen, die angebracht, entfernt, gewechselt oder anders gruppiert werden können, um das System an neue Bedingungen anzupassen. Ein monolithisches System hingegen kann solche Anpassungen nur in Form einer Strukturumwandlung bewerkstelligen, wenn die [[Parametrisierter Algorithmus|Parametrisierung]] seiner Funktionen nicht eine passende Einstellung erlaubt.
* Flexibilität im Angebot: größere Produktvarietät
* [[Herstellkosten|billigere Herstellung]] durch baugleiche [[Serienfertigung|Serien]] und einfachere [[Montage (Produktion)|Montageprozesse]]
* Wartung: kostengünstige [[Reparatur]] durch Austausch der fehlerhaften Komponente

== Grenzen und Risiken der Modularisierung ==
''Verarbeitungsgeschwindigkeit und Anpassungsfähigkeit:''
Modularisierung hat dort ihre Grenzen, wo ein System sehr spezifischen Anforderungen gerecht werden muss, insbesondere im Hinblick auf Verarbeitungsgeschwindigkeit (Performance) oder problemspezifische Anpassungsfähigkeit. Ursache sind in der Regel die hohen Kosten
* für eine Änderung bzw. Erweiterung der Schnittstellen zwischen den Modulen, wenn sich durch den Austausch eines Moduls allein keine weitere Verbesserung mehr erzielen lässt;
* für eine Anpassung des Gesamtsystems (sofern überhaupt möglich) an kundenindividuelle bzw. problemspezifische Anforderungen.
In der Informationstechnik beispielsweise gibt es Unternehmen, die sich darauf spezialisiert haben, kunden-individuelle Software-Lösungen ([[Individualsoftware]]) zu entwickeln. Solche [[Komponente (Software)|Komponenten]] werden von ihren Kunden (trotz ggf. höherer Kosten) ergänzend oder alternativ zu [[Standardsoftware]] eingesetzt, wenn diese den [[Anforderung (Informatik)|Anforderungen]] nicht genügt.

''Hemmende Wirkung richtungsweisender Innovationen:''
Wie Fleming und Sorenson, welche Daten des US-amerikanischen Patentamts aus einem Zeitraum von 200 Jahren auswerteten, feststellen, kann der Trend zu hochgradiger Modularität die Innovationsfähigkeit eines Systems negativ beeinflussen. Während einerseits ein modulares Design die Produktentwicklung vorhersagbar machen kann und die Innovationsraten der einzelnen Module beschleunigt, kann andererseits ein Punkt erreicht werden, wo Modularisierung die Chancen für einen richtungsweisenden modulübergreifenden Durchbruch in der Produktentwicklung untergräbt. Gemäß der Untersuchung ihres Modells übt das Abhängigkeitsverhältnis zwischen den Modulen den größten Einfluss auf die Wahrscheinlichkeit modulübergreifender und somit potenziell richtungsweisender Innovationen aus. Ihr Modell ergibt, dass gute Innovationen in Situationen hoher Abhängigkeiten zwischen den Modulen signifikantere Auswirkungen haben können als die besten Innovationen in Situationen niedriger Abhängigkeiten. Um den Nutzen von Innovationen zu optimieren, empfehlen sie daher, eine Balance zwischen dem Grad der Abhängigkeiten und Unabhängigkeiten innerhalb eines Systems zu finden.<ref>{{Literatur |Autor=Lee Fleming, Olav Sorenson |Titel=Technology as a complex adaptive system: evidence from patent data |Sammelwerk=Research Policy |Band=30 |Nummer=7 |Datum=2001 |Seiten=1019–1039 |DOI=10.1016/S0048-7333(00)00135-9}}</ref>

''Imitierbarkeit:''
Gerade die Vorhersagbarkeit, die für einen modularen Ansatz typisch ist, kann dazu führen, dass ein konkurrierendes Unternehmen ähnliche Produkte entwickelt.<ref name="FlemingSorenson">L. Fleming, O. Sorenson: [http://sjbae.pbworks.com/w/file/45794268/Fleming%20%26%20Sorenson_2001.pdf ''The dangers of modularity.''] In: ''Harvard Business Review.'' 79(8), 2001, S. 20–21.</ref>

''Kooperationsfähigkeit und strategische Steuerung:''
Unter den organisatorischen Einheiten, die für je einzelne Module in der Produktentwicklung bzw. einzelne Prozesse im Unternehmen zuständig sind, kann es zu einem verringerten Austausch von (implizitem) Wissen und zu einer reduzierten Kooperationsfähigkeit kommen. Dadurch kann der Blick auf die Performance des gesamten Systems verstellt werden.<ref name="Osterloh" />

== Anwendungsbeispiele ==
* ''[[Normteil]]e'' (genormte [[Bauteil (Technik)|technische Bauteile]] als funktionelle [[Einzelteil]]e) und standardisierte [[Baugruppe]]n (Montagegruppen) in [[Maschinenbau]] und anderen Gebieten der [[Technik]], über die etwa ''Baukastenstücklisten'' (nach [[DIN 6789]]) geführt werden. Bedeutende Einsatzgebiete sind u. a.:
** [[Raumstation]]en
** [[Plattform (Automobil)|Plattformstrategie]] im Fahrzeugbau
** in [[Mikrocomputer|Computern]], in denen austauschbare Bauteile über standardisierte Schnittstellen kommunizieren (z.&nbsp;B. [[Steckkarte]]n oder [[Speichermodul]]e). Der [[IBM Personal Computer|IBM-PC]] und seine Nachfolger verdanken ihre Verbreitung auch und gerade diesem Effekt.
** [[Modularer Maschinenbau]], insbesondere technische Großanlagen wie Kraftwerke und Verkehrsanlagen, aber auch kleinere Maschinen wie ein [[modularer Seilzug]]
** Elektrische und elektronische Bauelemente: Bestückung von [[Leiterplatte|Platinen]]
** Das 19-Zoll-Aufbausystem ([[Rack]]) der [[Elektronik]]
** [[Lego]], [[Fischertechnik]] oder [[Rasti]]
* In [[Architektur]] und [[Bauwesen]]
** In Serie vorgefertigte [[Bauteil (Bauwesen)|Bauteile]]
** [[Gebäude]] aus modularen Raumelementen (zum Beispiel [[Containergebäude]] oder [[Raumzellenbauweise|Modulbauten]])
** [[Gebäudekomplex]]e, insbesondere Hochhäuser, aus modularen Gebäudeteilen ([[Gebäudetrakt|Gebäudeflügeln]]), zum Beispiel das [[Crystal Palace (Gebäude)|Crystal Palace (London, 1851)]]
** Möbelbausysteme wie [[USM Haller]]
* [[Komponentenbasierte Entwicklung]] von Software, Gruppen von Befehlen als funktionsorientierte [[Komponente (Software)|Komponenten]] in [[Computerprogramm]]en, die eine bestimmte Funktion erfüllt und über eine definierte [[Schnittstelle]] aufgerufen wird:
** [[Modul (Software)|Softwaremodule]] für wiederkehrende Aufgaben
** [[Kernel-Modul]]e, Betriebssystemkomponenten, die nur bei Bedarf aktiviert werden, im Gegensatz zum [[Kernel (Betriebssystem)|Kernel]]
* [[Geschäftsprozessmodellierung]] bzw. [[Business Process Reengineering]] zur Optimierung der Abläufe in einem Unternehmen
* [[Modul (Hochschule)|gestufte Studiengänge]] im Hochschulwesen
* [[Content-Management]] bzw. [[Wissensmodellierung]] mit Hilfe eines [[Wiki]]s modularisiert das zu dokumentierende Wissen äußerst feingranular. Die Schnittstellen sind die Links zwischen den einzelnen Wissenseinheiten (also Wiki-Seiten).
* beim Militär, welche sich zu einem modularen Aufbau hin wandelt, siehe [[Transformation (Militärwissenschaft)]]
* bei [[Modularer Synthesizer|Modularen Synthesizern]] zur Klangsynthese
* Produktions- und Kompositionstechnik für Popmusik entwickelt von [[Brian Wilson]], bekannt geworden durch [[Good Vibrations]] und [[Smile (Album)|Smile]]
* [[Modularer Modelleisenbahnbau]] bei großen Modelleisenbahnanlagen
* bedarfsgerechte Dosierung der waschaktiven Substanzen durch ein [[Waschmittel]]-Baukastensystem, das es beispielsweise erlaubt, den benötigten Wasserenthärter - je nach Wasserhärte vor Ort - getrennt zuzusetzen und somit, diesen unabhängig zu dosieren
* Modularis ist ein System, das eine [[Physical Computing|Physical-Computing-Plattform]] als Baukasten bereitstellt<ref>[http://www.aevum-mechatronik.de/modularis ''Modularis.'']</ref>

== Siehe auch ==
* [[Integrationsmodell#Baukasten|Integrationsmodell: Baukasten & Modularität]]

== Literatur ==
* Margit Osterloh: ''Das Management von Strukturen und Prozessen.'' IOU – Institut für Organisation und Unternehmenstheorien, Universität Zürich, 2. Mai 2006 ([http://www.uzh.ch/iou/orga/ssl-dir/wiki/uploads/Main/V06_OrgaIIa.pdf PDF] auf uzh.ch).
* K. B. Clark, C. Y. Baldwin: ''Design Rules.'' Band 1: ''The Power of Modularity.'' MIT Press, Cambridge, Massachusetts 2000, ISBN 0-262-02466-7 (englisch).
* Ron Sanchez im Interview: [http://www.connected.org/media/modular.html ''Modularity: upgrading to the next generation design architecture.''] In: ''Connected Magazine Dossiers.'' 12. Mai 2000 (englisch; Professor für Strategie und Technologie Management am IMD - International Institute for Management Development, Lausanne).
* Stefano Brusoni, Andrea Prencipe: ''Unpacking the black box of modularity: Technologies, products and organizations.'' In: ''Industrial and Corporate Change.'' Band 10. 2001, S. 179–205 (englisch; [http://myweb.rollins.edu/tlairson/pek/modularity.pdf PDF: 1,3&nbsp;MB] auf rollins.edu).
* Günther Schuh: ''Produktkomplexität managen: Strategien - Methoden - Tools.'' Hanser, München, August 2017, ISBN 978-3-446-45225-1.
* Günther Schuh: ''Leitfaden zur Baukastengestaltung.'' VDMA, Frankfurt/M. 2015, ISBN 978-3-8163-0674-0.

== Weblinks ==
{{Wiktionary}}

== Einzelnachweise ==
<references responsive />

{{SORTIERUNG:Modularitat}}
[[Kategorie:Produktionswirtschaft]]
[[Kategorie:Konstruktionslehre]]
[[Kategorie:Standardisierung]]
[[Kategorie:Softwarearchitektur]]
[[Kategorie:Geschäftsprozessmanagement]]
[[Kategorie:Schlanke Produktion]]
[[Kategorie:Modulares Design]]