EntwurfeinesintegrativenGrundmodells fürProduktkonﬁguratoren · 2018. 8. 10. · 1.1 Motivation...

Entwurf eines integrativen Grundmodellsfür Produktkonfiguratoren

– Diplomarbeit –

zur Erlangung des akademischen Grades Diplom-Informatiker

eingereicht vonAndreas Krug

[email protected] am 15.09.1985 in Ilmenau/Thüringen

BetreuerDipl.-Inf. Matthias Liebisch

Prof. Dr. Klaus Küspert

Friedrich-Schiller-Universität JenaFakultät für Mathematik und Informatik

Institut für InformatikLehrstuhl für Datenbanken und Informationssysteme

Ernst-Abbe-Platz 1-407743 Jena

Juni 2010

KurzfassungProduktkonfiguratoren haben sich seit den achtziger Jahren zu einem zentralen Instru-ment der Interaktion zwischen den verschiedenen Teilnehmern eines Wirtschaftsmarktesentwickelt. So dienen derartige Systeme einerseits der Bedürfnisbefriedigung des Kundenin Bezug auf die Auswahl eines seinen Vorstellungen entsprechenden Produktes und ande-rerseits der Gewinnmaximierung bzw. Absatzsteigerung des Unternehmens in Bezug aufden Verkauf der eigenen Produkte. Über die vergangenen Jahrzehnte hinweg verändertesich aber auch die innerbetriebliche Systemlandschaft hinsichtlich der internen und ex-ternen Informationserfassung und -verarbeitung. Dies ist einer der Gründe, warum dieFrage nach dem Einsatz von Produktkonfiguratoren in der Gegenwart keine besondereBeachtung mehr erfährt. Vielmehr liegt der Fokus auf Fragestellungen, wie z. B. derartigeSysteme in ein bestehendes Unternehmensumfeld integriert werden können und welcheGrundbestandteile ein solcher Produktkonfigurator vorweisen sollte.Die vorliegende Arbeit konzentriert sich auf die Beantwortung dieser Fragen. Hierzu wer-den in einem ersten Schritt die erforderlichen Grundlagen aufbereitet und vermittelt. Ineinem zweiten Schritt erfolgt die Definition einer Globalklassifikation, welche die Vielfaltder gegenwärtigen Konfiguratorsysteme aufzeigen und veranschaulichen soll. Zudem wirdauf die in einem derartigen System vorhandenen Informationsarten eingegangen. Demschließt sich die Vorstellung eines integrativen Grundmodells für Produktkonfiguratorenan. Hierbei werden die unterschiedlichen Bestandteile und deren Abhängigkeiten betrach-tet, das Modell als solches validiert sowie zusätzlich nutzbare Synergieeffekte aufgezeigt.Abgerundet wird die vorliegende Arbeit durch die Veranschaulichung von vier Prozessen,die in derartigen Produktkonfiguratoren von zentraler Bedeutung sind.

i

DanksagungAn dieser Stelle sei die Aufmerksamkeit auf all jene gerichtet, die mich während meinesStudiums unterstützt und an meine Ziele geglaubt haben. Ihnen allen möchte ich aufdiesem Weg herzlichst Danke sagen.Ein besonderer Dank gilt meinem Betreuer, Dipl.-Inf. Matthias Liebisch, für die kooperati-ve und sehr angenehme Betreuung, die ich im Laufe des Schreibens dieser Arbeit erfahrendurfte. Seine fachlich konstruktiven Anregungen und Kritiken waren mir stets eine wert-volle Hilfestellung. Ebenso bedanken möchte ich mich bei Prof. Dr. Klaus Küspert für seinepraxisorientierte Lehre im Hauptstudium, durch die ich mein Wissen auf dem gewähltenVertiefungsgebiet der Datenbanken- und Informationssysteme anreichern konnte.Danken möchte ich zudem der Heinz-Nixdorf-Stiftungsprofessur für Praktische Informatik,in Personen Prof. Dr. Birgitta König-Ries und Dipl.-Inf. Ulrich Küster. In der dreieinhalb-jährigen Tätigkeit als HiWi konnte ich auf diesem Wege hinter die Kulissen der Universitätund der Lehre schauen und so das Studium aus einem anderen Blickwinkel kennenlernen,nebenbei erleichterte mir die Anstellung aber auch die Finanzierung meines Studiums.Das Studium der Informatik mit all seinen Schwierigkeiten und Herausforderungen, abervordergründig mit den Höhepunkten des studentischen Daseins, verbinde ich mit einerwundervollen Person, die ich während des Studiums in Jena kennen gelernt habe. Auf die-sem Wege möchte ich mich bei meiner Verlobten Katharina Leonhardt für die jederzeitigeUnterstützung, das geduldige Probelesen meiner Niederschriften und die wertvollen undkreativen Ideen sehr bedanken.Die vorliegende Arbeit möchte ich meinen Eltern, Karin und Werner Krug, widmen. Siehaben mich über die Jahre mit aller Kraft unterstützt und mir stets mit Rat und Tatzur Seite gestanden. Mit ihrer Unterstützung haben sie einen wesentlichen Beitrag zumGelingen meines Studiums der Informatik geleistet. Ich bin sehr froh und dankbar, dasses sie gibt.

iii

Inhaltsverzeichnis

1 Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Grundlagen 52.1 Produkte und deren Herstellung . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Produktmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 Produktarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.3.1 Materielle Produkte . . . . . . . . . . . . . . . . . . . . . . . 102.1.3.2 Immaterielle Produkte . . . . . . . . . . . . . . . . . . . . . 11

2.1.4 Typen der Produktfertigung . . . . . . . . . . . . . . . . . . . . . . . . 112.1.4.1 Typisierung nach dem Absatzmarkt . . . . . . . . . . . . . 112.1.4.2 Typisierung nach der Individualität und Stückzahl . . . . 12

2.1.5 Prozess der Produktentstehung . . . . . . . . . . . . . . . . . . . . . . 142.1.5.1 Konzept der Absatzentwicklung . . . . . . . . . . . . . . . . 152.1.5.2 Konzept der Tätigkeiten . . . . . . . . . . . . . . . . . . . . 17

2.2 Produktkonfiguratoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.2 Einsatzbereiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.3 Produktbezogene Voraussetzungen . . . . . . . . . . . . . . . . . . . . 212.2.4 Anforderungen und Nutzen . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.4.1 Anforderungen aus Kundensicht . . . . . . . . . . . . . . . . 242.2.4.2 Anforderungen aus Anbietersicht . . . . . . . . . . . . . . . 262.2.4.3 Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.5 MVC-Architekturmuster . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2.6 Anwendungsbeispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

v

vi INHALTSVERZEICHNIS

2.2.6.1 CREALIS® . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.2.6.2 MyMuesli Cerealienkonfigurator . . . . . . . . . . . . . . . . 322.2.6.3 Traiteur Carl 18.91™ Konfigurator . . . . . . . . . . . . . . 32

2.3 Unternehmensintegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.2 Sichtweisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3.3 Grundlegende Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3 Klassifikation 393.1 Kategorien der Globalklassifikation . . . . . . . . . . . . . . . . . . . . . . . . 393.2 Klassen der Globalklassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.1 Klassen der Basiskonzeptkategorie . . . . . . . . . . . . . . . . . . . . 413.2.1.1 Gestaltungsspielraum . . . . . . . . . . . . . . . . . . . . . . 413.2.1.2 Universalität . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2.1.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . 433.2.1.4 Anwenderart . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2.1.5 Einsatzgebiet, Produktart und Produktfertigung . . . . . . 44

3.2.2 Klassen der Datenmodellkategorie . . . . . . . . . . . . . . . . . . . . 443.2.2.1 Rekursionsgrad . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2.2.2 Produktwissensevolution . . . . . . . . . . . . . . . . . . . . 453.2.2.3 Integrationsgrad . . . . . . . . . . . . . . . . . . . . . . . . . 453.2.2.4 Persistierungsebene . . . . . . . . . . . . . . . . . . . . . . . 46

3.2.3 Klassen der Präsentations- und Darstellungskategorie . . . . . . . . 483.2.3.1 Startzustand der Konfiguration . . . . . . . . . . . . . . . . 483.2.3.2 Konfigurationsverlauf . . . . . . . . . . . . . . . . . . . . . . 493.2.3.3 Optionsdarstellung . . . . . . . . . . . . . . . . . . . . . . . . 503.2.3.4 Optionskategorisierung . . . . . . . . . . . . . . . . . . . . . 503.2.3.5 Entscheidungsart . . . . . . . . . . . . . . . . . . . . . . . . . 513.2.3.6 Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.2.3.7 Preisdarstellung . . . . . . . . . . . . . . . . . . . . . . . . . 523.2.3.8 Verkaufsunterstützung . . . . . . . . . . . . . . . . . . . . . 523.2.3.9 Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.2.4 Klassen der Logik- und Architekturkategorie . . . . . . . . . . . . . . 533.2.4.1 Zeitpunkt der Abhängigkeitsprüfung . . . . . . . . . . . . . 533.2.4.2 Systeminteraktion . . . . . . . . . . . . . . . . . . . . . . . . 543.2.4.3 Architekturszenario . . . . . . . . . . . . . . . . . . . . . . . 55

INHALTSVERZEICHNIS vii

3.2.4.4 Art der Abhängigkeitsprüfung . . . . . . . . . . . . . . . . . 563.3 Datensemantische Klassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.3.1 Modelldaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.3.2 Oberflächendaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.3.3 Konfigurationsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.3.4 Verkehrsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.3.5 Administrationsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.3.6 Integrationsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4 Integratives Grundmodell 614.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.3 Module und Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.3.1 Module des integrativen Grundmodells . . . . . . . . . . . . . . . . . 644.3.1.1 Model-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.3.1.2 View-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.3.1.3 Controller-Ebene . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.3.2 Modulabhängigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.3.2.1 Interaktionswerk . . . . . . . . . . . . . . . . . . . . . . . . . 724.3.2.2 Dialogwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.3.2.3 Pflegesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.3.2.4 Aktivitätenprotokollierungssystem . . . . . . . . . . . . . . 754.3.2.5 Inferenzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.3.2.6 Steuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.3.2.7 Datenaufbereitungs- und Datenverteilungssystem . . . . . 76

4.3.3 Datenzugriffe und Persistierung . . . . . . . . . . . . . . . . . . . . . . 764.3.3.1 Lesende Zugriffe . . . . . . . . . . . . . . . . . . . . . . . . . 764.3.3.2 Schreibende Zugriffe . . . . . . . . . . . . . . . . . . . . . . . 78

4.4 Modellvalidierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.4.1 Anwendungsvalidierung . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.4.1.1 Szenario 1: Produktzusammenstellung durch Kunden . . . 794.4.1.2 Szenario 2: Produktdatenänderung durch Mitarbeiter . . . 80

4.4.2 Anforderungsvalidierung . . . . . . . . . . . . . . . . . . . . . . . . . . 824.4.2.1 Anforderungen aus Kundensicht . . . . . . . . . . . . . . . . 834.4.2.2 Anforderungen aus Anbietersicht . . . . . . . . . . . . . . . 84

4.5 Synergieeffekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

viii INHALTSVERZEICHNIS

4.5.1 Produktbezogene Erkenntnisgewinnung . . . . . . . . . . . . . . . . . 854.5.2 Kundenbezogene Erkenntnisgewinnung . . . . . . . . . . . . . . . . . 864.5.3 Automatisierte Vertriebsunterstützung . . . . . . . . . . . . . . . . . 874.5.4 Wissenserweiterte Kundenbetreuung . . . . . . . . . . . . . . . . . . . 87

5 Prozesse und deren Dependenz 895.1 Definition und Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.2 Kundenseitige Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.2.1 Konfigurationsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.2.2 Bestellprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.3 Anbieterseitige Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.3.1 Produktmodularisierung . . . . . . . . . . . . . . . . . . . . . . . . . . 955.3.2 Pflege der Modelldaten . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6 Zusammenfassung und Ausblick 996.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

A Definitionen für „Produktkonfigurator“ 103

Literaturverzeichnis 105

Abbildungsverzeichnis 111

Tabellenverzeichnis 113

Abkürzungsverzeichnis 115

Kapitel 1

Einleitung

Dieses Kapitel dient der Motivation dieser Diplomarbeit und gibt einen Überblick überdie angestrebten Ziele. Zudem wird der Aufbau der Arbeit vorgestellt.

1.1 Motivation

Craig O. McCaw [Ame10], ein amerikanischer Pionier der Telekommunikation und Grün-der der McCaw Cellular Incorporated, welche heute der AT&T Wireless Services Incorpo-rated1 zugeordnet ist, sagte einst sinngemäß:

„Es gibt Momente in der Geschichte, da treffen ein Unternehmer, eine Tech-nik und die Bedürfnisse der Menschen zusammen“.

Für die Gegenwart lässt sich diese Situationsbeschreibung auf die alltäglichen Geschäfts-beziehungen übertragen. Während der Unternehmer als Anbieter seiner Produkte bestrebtist, deren Absatz zu steigern und sie gewinnmaximierend zu verkaufen, ist der Mensch alsKonsument oder Abnehmer daran interessiert, ein zu seinen Vorstellungen und Wünschenbestmöglich passendes Produkt auf dem Markt zu finden. Im Kern geht es bei dieser Bezie-hung also um die Realisierung zweier Ziele: die Absatzsteigerung bzw. Gewinnmaximierungeinerseits und die Bedürfnisbefriedigung andererseits. Eine Möglichkeit zur Zielerreichungstellt dabei das individuelle Zusammenstellen der Produkte dar. Dieses kann entweder aufmanuellem Wege oder aber in automatisierter Form durch die Einbindung einer entspre-chenden Technik erfolgen. Ein bedeutsames Instrument, welches diese Technik liefert, istein Produktkonfigurator, der zugleich auch das zentrale Betrachtungsobjekt in der vorlie-genden Arbeit darstellt.Produktkonfiguratoren haben in der Vergangenheit neben dem eigenen Entwicklungspro-zess auch einen Wandel in verschiedenen Bereichen herbeigeführt, so unter anderem imProzess der Produktentstehung und im Produktvertrieb. So wurde bereits Anfang derachtziger Jahre die Thematik der Produktzusammenstellung in der Industrie vordergrün-dig betrachtet. Eine Intensivierung der wissenschaftlichen Forschung über Produktkonfi-guratoren ist ab Mitte der neunziger Jahre zu verzeichnen [Sch06]. Im selben Zeitfens-ter lässt sich bezogen auf die Unternehmen zudem festzustellen, dass sich deren Sys-temlandschaft im Hinblick auf die interne wie auch externe Informationserfassung und

1http://www.att.com/

1

2 KAPITEL 1. EINLEITUNG

-verarbeitung grundlegend verändert hat. So zählt mittlerweile der Einsatz von entspre-chenden Produktinformations- und Kundenverwaltungssystemen in der Gegenwart zumindustriellen Standard.

Wurde also in der Vergangenheit am Puls der Wirtschaft und in der Wissenschaft über dieEinführung von Produktkonfiguratoren diskutiert, so kann man für die Gegenwart festhal-ten, dass diese Frage weniger Aufmerksamkeit erfährt, da der Einsatz von Produktkonfigu-ratoren zur beschriebenen Zielerreichung zahlreich erprobt wurde. Von gegenwärtiger Be-deutung ist dagegen die Fragestellung, inwiefern vorhandene Produktkonfiguratoren in einbestehendes Unternehmensumfeld integriert werden können, um dadurch notwendige Syn-ergieeffekte für das Unternehmen, die Geschäftspartner und die Kunden herbeizuführen.Damit im Zusammenhang stehen auch die Fragen, auf welchem Weg eine Systemintegrati-on umgesetzt werden kann und welche zentralen Anforderungen ein derart eingebundenesSystem zu erfüllen hat. Zusätzlich muss mit Blick auf die selbstbezogene Entwicklung ge-klärt werden, was überhaupt die Grundbestandteile eines derartigen Systems sind bzw.sein sollten und wie diese miteinander in Interaktion stehen.

Die vorliegende Arbeit konzentriert sich auf die Beantwortung der obigen Fragestellun-gen, indem sie den Entwurf eines integrativen Grundmodells für Produktkonfiguratorenvorstellt. Die konkreten Ziele der Diplomarbeit sind im folgenden Abschnitt definiert.

1.2 Ziele

Die elementaren Ziele dieser Diplomarbeit lassen sich wie folgt zusammenfassen:

1. GrundlagenwissenDie Arbeit soll für die Themengebiete Produkte und deren Herstellung, Produkt-konfiguratoren und Unternehmensintegration Grundlagenwissen vermitteln, um soein inhaltliches Fundament für die späteren Ausführungen zur Verfügung zu stellen.

2. KlassifikationAufbauend auf bestehende Klassifikationsansätze für Produktkonfiguratoren soll einumfassender Ansatz für eine Typisierung der Konfiguratorsysteme vorgestellt wer-den. Dies schließt die Erweiterung eines Konzeptes zur datensemantischen Klassifi-kation ein.

3. Integratives GrundmodellDas zentrale Ziel dieser Arbeit ist der Entwurf eines integrativen Grundmodells fürProduktkonfiguratoren, welches einerseits die grundlegenden Anforderungen erfülltund andererseits als Referenzmodell für Implementierungen dienen kann.

4. Prozesse in ProduktkonfiguratorenEin weiteres Vorhaben besteht in der Betrachtung von ausgewählten Prozessen, dienach dem integrativen Grundmodell in Produktkonfiguratoren von zentraler Bedeu-tung sind.

1.3. AUFBAU 3

1.3 Aufbau

In Anlehnung an die im Abschnitt 1.2 formulierten Ziele der Diplomarbeit schließen sichweitere Kapitel an, die im Folgenden kurz umrissen werden.Im Kapitel 2 werden die zentralen Begriffe und Merkmale der Themengebiete Produkteund deren Herstellung, Produktkonfiguratoren sowie Unternehmensintegration vorgestellt.Es erfolgt zudem eine inhaltsbezogene Verknüpfung der Themenbereiche untereinander.Das Kapitel 3 wirft einen Blick auf die Vielfalt der Produktkonfiguratoren. So werdenanhand einer Globalklassifikation 24 verschiedene Dimensionen aufgezeigt, nach denenKonfiguratorsysteme differenziert werden können. Darüber hinaus wird eine erweitertedatensemantische Klassifikation vorgestellt, welche namensgebend genau jene Daten alsKlassifikationsobjekt betrachtet, die in einem derartigen System von Bedeutung sind.Im Kapitel 4 wird der Entwurf des integrativen Grundmodells für Produktkonfiguratorenpräsentiert. Hierzu werden in einem ersten Schritt der Begriff des Modells und der Vorgangder Modellbildung beschrieben. Darauf aufbauend werden die zentralen Bestandteile desModells erklärt und deren unterschiedliche Abhängigkeiten beschrieben. Abschließend er-folgt eine Validierung des Modells sowie das Aufzeigen einer Auswahl von Synergieeffekten,welche durch die Integration von Produktkonfiguratoren herbeigeführt werden können.Das Kapitel 5 hat die Betrachtung von Prozessen zum Inhalt, die im Sinne des inte-grativen Grundmodells in Produktkonfiguratoren von zentraler Bedeutung sind. So wirdstellvertretend auf den Konfigurations- und Bestellprozess einerseits und die Prozesse derProduktmodularisierung sowie der Modelldatenpflege andererseits eingegangen.Kapitel 6 fasst schließlich die vorliegende Arbeit zusammen und gibt einen Ausblick aufweiterführende Themen und wissenschaftliche Betrachtungen.Einen schematischen Überblick über die Kapitel und Abschnitte der Arbeit zeigt die Ab-bildung 1.1 auf der nächsten Seite.

4 KAPITEL 1. EINLEITUNG

Kapitel 1: Einleitung

Kapitel 2: Grundlagen

Kapitel 3: Klassifikation

Kapitel 4: Integratives Grundmodell

Kapitel 5: Prozesse und deren Dependenz

Kapitel 6: Zusammenfassung und Ausblick

1.1 Motivation 1.2 Ziele 1.3 Aufbau

2.1 Produkte und deren Herstellung 2.2 Produktkonfiguratoren 2.3 Unternehmensintegration

3.1 Kategorien der Globalklassifikation 3.2 Klassen der Globalklassifikation 3.3 Datensemantische Klassifikation

4.1 Definition

En

twu

rf e

ines

in

tegra

tive

n G

run

dm

od

ells

fü

r P

rod

uk

tkon

figu

rato

ren

4.2 Vorgehensweise 4.3 Module und Architektur 4.4 Modellvalidierung 4.5 Synergieeffekte

5.1 Definition und Notation 5.2 Kundenseitige Prozesse 5.3 Anbieterseitige Prozesse

6.1 Zusammenfassung 6.2 Ausblick

Abbildung 1.1: Kapitelübersicht der Diplomarbeit

Kapitel 2

Grundlagen

In diesem Kapitel werden die für diese Arbeit relevanten Begrifflichkeiten und Merkma-le der Gebiete Produkte und deren Herstellung, Produktkonfiguratoren sowie Unterneh-mensintegration erläutert.

2.1 Produkte und deren Herstellung

Dieser Abschnitt widmet sich zunächst der Begriffsklärung, dem Produktmodell, der Dar-legung verschiedener Produktarten und unterschiedlicher Fertigungstypen sowie abschlie-ßend dem Prozess der Produktentstehung.

2.1.1 Definitionen

Der Begriff Produkt wird homonym gebraucht [Mil09]. Neben dem mathematischen Pro-dukt von Faktoren und dem chemischen Produkt von Stoffen gibt es u. a. eine wirtschaft-liche Bedeutung, die hier im Vordergrund stehen soll. Dabei wird das Wort Produkt alsAbleitung des Verbs produzieren verstanden. Dieses findet seinen Ursprung im lateinischenWort producere und bedeutet sinngemäß „hervorbringen“. Der erste nachweisliche Zusam-menhang des Produktbegriffs in der heute bekannten Form führt zurück nach England indas Jahr 1575 [Har09].Innerhalb des Wirtschafts- und Wissenschaftsgebiets gibt es wiederum unterschiedlicheDefinitionsansätze und Synonyme für den Produktbegriff. So definiert Bieniek in [Bie01]das Produkt als ein unter den „Elementarfaktoren Arbeit, Betriebsmittel und Rohstoffehergestelltes, gebrauchs- beziehungsweise verkaufsfähiges Erzeugnis, das sowohl materiel-ler als auch immaterieller Natur sein kann“. Die in diesem Sinne als Rohstoffe bezeichnetenEinheiten werden in dieser Arbeit als Werkstoffe bezeichnet. Das in der Definition vor-kommende Erzeugnis lässt sich nach DIN 6789 verstehen als ein „in sich geschlossener,aus einer Anzahl von Gruppen und/oder Teilen bestehender, funktionsfähiger Gegenstandals Fertigungsergebnis“. Eine allgemeine Form findet man dagegen in [SSEM05], nachder ein Produkt ein Erzeugnis, ein Ertrag, eine Folge oder ein Ergebnis (einer Abfolgevon Aktionen) ist. Einen ganz anderen Ansatz bevorzugt Fandel, indem er in [Fan05]den Produktbegriff definiert als Obermenge für Endprodukte, Zwischenprodukte und Ab-fallprodukte. Hingegen versteht man nach [SG03] unter einem Produkt unter anderem

5

6 KAPITEL 2. GRUNDLAGEN

ein „materielles Ergebnis menschlicher Arbeit, das der Befriedigung menschlicher Bedürf-nisse dient“. So ähnlich wird der Begriff des Produktes auch in [KASW06] definiert als„jedes Objekt, das auf einem Markt zur Beachtung oder Wahl, zum Kauf, zur Benut-zung oder zum Verbrauch oder Verzehr angeboten wird und geeignet ist, damit Wünscheoder Bedürfnisse zu befriedigen“. Und auch Kistner und Steven sehen das Ergebnis imVordergrund. Sie definieren den Produktbegriff als „das Ergebnis der Produktion“ unddefinieren letztere wiederum als „die Kombination von Gütern und Dienstleistungen undderen Transformation in andere Güter und Dienstleistungen“ [KS02].Für den Begriff der Produktion gibt es ebenso zahlreiche verschiedene Definitionen. NachKüpper umfasst die Produktion „die gesamte betriebliche Wertschöpfungskette und be-zieht sich auf jede Form der Gütererstellung“ [Küp09]. Jung erklärt Produktion im Sinneder Fertigstellung als „die eigentliche Be- und Verarbeitung von Rohstoffen zu Halb- undFertigfabrikaten“ [Jun06]. Domschke formuliert den Produktionsbegriff als ein „Prozess,bei dem zur Herstellung von Gütern Produktionsfaktoren kombiniert und transformiertwerden. Die hergestellten Güter werden als Produkte bezeichnet“, womit sich der Kreiszum Produktbegriff schließt. Im weiteren Verlauf der Arbeit werden für den Begriff derProduktion die Synonyme Herstellung und Fertigung verwendet.Zusammenfassend bleibt festzuhalten, dass ein Produkt in dieser Arbeit

• als Synonym für Güter, Waren oder Dienstleistungen verwendet wird,

• das Ergebnis eines Herstellungsprozesses ist,

• gebrauchs- oder verbrauchsfähigen Charakter besitzt,

• materieller oder immaterieller Natur sein kann,

• es in verschiedene Dimensionen kategorisierbar ist und

• als wesentliches Instrument der konsumentenbezogenen Bedürfnisbefriedigung dient.

Ergänzend zu diesen Merkmalen eines Produktes gelten die folgenden zwei Definitionen(siehe dazu auch Abbildung 2.1):Definition 1: ProduktEin Produkt ist durch seine Eigenschaften charakterisiert und aus verschiedenen (Pro-dukt-) Komponenten zusammengesetzt. Die Kombination der (Produkt-) Komponentenkann durch eine manuelle oder automatisierte Vorgehensweise bestimmt werden.

Definition 2: atomare (Produkt-) KomponenteEine atomare (Produkt-) Komponente ist das kleinstmögliche, nicht in weitere Kompo-nenten zerlegbare, Bestandteil eines Produktes.

Der Begriff der Komponente beruht hierbei auf einer rekursiv zusammengesetzten Struk-tur. Das bedeutet, dass eine Komponente wiederum aus anderen Komponenten zusammen-gesetzt sein kann. Dies lässt sich theoretisch beliebig, praktisch jedoch nur begrenzt (inBezug auf die Teilbarkeit einer Komponente) fortsetzen. Komponenten lassen sich zudemnach [HK08] unterscheiden in Basiskomponenten, optionale und benötigte Komponenten.

2.1. PRODUKTE UND DEREN HERSTELLUNG 7

Basiskomponenten entsprechen der Grunddefinition eines Produktes, optionale Kompo-nenten können, müssen aber nicht Bestandteil des Produktes sein und werden in dieserArbeit fortan als Optionalkomponenten bezeichnet. Komponenten, die bei bestimmtenKombinationen zwingend erforderlich sind, werden auch als benötigte Komponenten undim Rahmen dieser Arbeit als Implikativkomponenten bezeichnet. Zur besseren Verständ-lichkeit des Begriffes der Implikativkomponente dient das folgende vereinfachte Beispiel:Ein Produkt, hier z. B. ein Auto, kann in seiner Zusammenstellung in verschiedenen Be-reichen variiert werden. So gibt es u. a. die Wahl zwischen einer „Gangschaltung“ odereiner „Automatikschaltung“. Abhängig von dieser Wahl wird ein aus verschiedenen Kom-ponenten zusammengehörendes System in das Auto gebaut. Hierdurch erhält dann dieKomponente „Kupplungspedal“ einen implikativen Charakter, der sich daraus ableitet,dass der Wahl der „Gangschaltung“ die Wahl der Komponente „Kupplungspedal“ folgenmuss, da diese zur Gewährleistung der Funktionalität zwingend erforderlich ist. Aus dembeschriebenen implikativen Charakter heraus folgt die Bezeichnung der Implikativkompo-nente.Bereits an dieser Stelle wird deutlich, dass die Zusammensetzung eines Produktes vonhoher Komplexität geprägt sein kann, was sich unvermeidlich auch auf den Prozess derZusammenstellung eines Produktes auswirkt.

Produkt

(Produkt-)

Komponente 1

(Produkt-)

Komponente n

. . . . . . . . . . . . . . . . . . . . . . . .

. . .

Abbildung 2.1: Rekursive Produkt-Komponenten-Zusammensetzung

Für die im Bezug zur Herstellung bereits erwähnten Produktionsfaktoren gibt es zweiwesentliche Einteilungen. Nach der volkswirtschaftlichen Unterteilung versteht man dar-unter die Faktoren Arbeit, Boden und Kapital. Diese Einteilungsart soll hier keine weitereBeachtung erfahren. Die bei der betriebswirtschaftlichen Einteilung [Bie01] erfassten ele-mentaren Faktoren hingegen werden im Folgenden betrachtet.Diemenschliche Arbeitskraft als Produktionsfaktor wird unterteilt in die ausführenden unddie dispositiven Tätigkeiten. Erstgenannte umfassen die Erbringung einer Dienstleistung,z. B. Buchhaltung oder Installationsarbeiten. Derartige Tätigkeiten werden auch als „ob-jektbezogene Arbeitsleistungen“ bezeichnet. Unter dispositiven Tätigkeiten werden z. B.Leitung, Planung oder Kontrolle innerhalb einer Organisation zusammengefasst.Betriebsmittel werden auch als „Potenzialfaktoren“ bezeichnet, da sie zusammen mit denausführenden Tätigkeiten das Leistungspotenzial bilden, welches im wiederholten Einsatzzur Herstellung von Produkten benötigt wird. Exemplarisch seien an dieser Stelle Maschi-nen genannt, aber auch Grundstücke und Gebäude als Sachprodukte sowie Arbeitspläneals immaterielle Produkte können dazu gezählt werden. Betriebsmittel gehen im Gegen-satz zu den folgenden Werkstoffen nicht direkt in das Produkt ein. Hiermit ist gemeint,


dass z. B. eine Maschine nicht Bestandteil eines Produktes wird, sondern „nur“ zu derenHerstellung in Form der Leistungserbringung beiträgt.

Unter Werkstoffen werden alle direkt in das Produkt eingehenden Stoffe zusammengefasst.Sie werden bei der Herstellung des Produktes verbraucht und müssen daher laufend be-schafft werden, weswegen sie auch als „Repetierfaktoren“ bezeichnet werden. Werkstoffewerden in Rohstoffe bzw. Vorprodukte, Hilfsstoffe und Betriebsstoffe unterteilt. Rohstoffebzw. Vorprodukte sind dabei wesentliche Bestandteile eines Produktes (z. B. Holz oderMetall). Stoffe, die auch in ein Produkt einfließen, aber keinen wesentlichen Bestandteildarstellen, werden Hilfsstoffe genannt (z. B. Klebstoff). Letztlich werden jene Stoffe, dienicht in das Produkt eingehen, aber trotzdem für die Herstellung benötigt werden (z. B.zum Betrieb der Maschinen als Betriebsmittel), als Betriebsstoffe bezeichnet. Beispielehierfür sind Kraftstoffe oder Elektrizität für die eben genannten Maschinen.

Es sei an dieser Stelle darauf hingewiesen, dass es weitere Ansätze zur Systematisierung derProduktionsfaktoren gibt, wie z. B. nach der Aktivität der Faktoren (siehe dazu [Küp09]).Diese sind aber im Rahmen der Arbeit nicht weiter relevant.

Auch der Begriff der Variante hat einen starken Bezug auf den Produktbegriff, weshalber hier kurze Betrachtung erfahren soll. Nach Blöch versteht man unter einer Variante„weitgehend übereinstimmende Erzeugnisarten, die sich jedoch in einzelnen Merkmalenunterscheiden“ [BI97]. Die Menge der Varianten lässt sich hinsichtlich ihrer Ausprägungenauf die Variantenvielfalt abbilden. Diese ist nach Bartuschat charakterisiert durch dieAnzahl der unterschiedlichen Ausführungsformen eines Teiles, einer Baugruppe oder einesProduktes. Sie ist unterteilt in die äußere und innere Vielfalt. Unter der äußeren Vielfaltist die „für den Kunden erkennbare, nach außen wirkende Vielfalt eines Produktes“ zu ver-stehen. Dagegen steht die innere Vielfalt für die „in der Produktion auftretende Vielfaltan Baugruppen und Teilen“ [Bar94]. Ein ganzheitlicher Ansatz zur Beherrschung der Vari-antenvielfalt im Rahmen der Zusammenstellung von Komponenten (siehe dazu Abschnitt2.2) und Produktherstellung (siehe dazu Abschnitt 2.1.4) wird als Variantenmanagementbezeichnet [Fra02].

2.1.2 Produktmodell

Bisher wurde das Produkt in Form der begrifflichen Definition in Hinblick auf dessenZusammensetzung und Fertigung betrachtet. Über ein Produkt und dessen Zusammen-setzung gibt es jedoch auch eine Menge an Informationen, die sich unter anderem in derreinen Beschreibung der Komponenten, der definitorischen Festlegung der Eigenschafts-werte oder aber den Abhängigkeiten zwischen den einzelnen Komponenten wiederfindenkönnen. Auch entstehen im gesamten Produktlebenszyklus (siehe hierzu Abschnitt 2.1.5)eine Vielzahl an Informationen über das Produkt. Für die Nutzung und Verwertung der-artiger Daten bedarf es zwangsläufig der systematisierten Speicherung. Dieser Aufgabewidmen sich die Produktmodelle.

Dabei versteht man unter dem Begriff des Produktmodells die Menge der Partialmodelle.Ein Partialmodell umfasst dabei „semantisch eng zusammenhängende Informationsinhal-te“ [Sch06]. So können beispielsweise Informationen über die Produktmerkmale, über dieZugehörigkeit eines Produktes zu verschiedenen Kundengruppen oder über die Anfor-derungen der Produkte in jeweils eigene Partialmodelle abgelegt werden. Dabei gibt es


innerhalb der Partialmodelle Beziehungen zwischen den einzelnen Informationen wie auchzwischen den verschiedenen Partialmodellen selber.Produktmodelle werden über die gesamte Lebensdauer eines Produktes mit Informatio-nen angereichert und stellen so zu jeder Zeit eine „Abbildung eines Produktes im Sinneeines Beschreibungsmodells dar“ [Sch06]. Zudem finden sie im gesamten Lebenszyklus An-wendung, u. a. im Rahmen der Konstruktion, Entwicklung und des Verkaufsprozesses. Sowerden z. B. Angebote für Kunden anhand der in einem Partialmodell definierten Anfor-derungen und anhand der vorhandenen Merkmalsbeschreibung detailliert erstellt.

2.1.3 Produktarten

Die Notwendigkeit eben genannter Produktmodelle im Sinne der Produktdefinition und-beschreibung zeigt auch der folgende Abschnitt auf. Wenn im Kontext der Zusammen-stellung von Komponenten von einem Produkt die Rede ist, dann sind die Produkte inihrer Charakteristik und Merkmalsausprägung in der Regel verschieden. Daher differen-ziert man eine Vielzahl von Produktarten, die in ihrer Zusammensetzung unterschiedlichstark verändert werden können.Scheer unterscheidet dabei die Produkte nach dem Einfluss des Kunden auf diese [Sch06].Der Kundeneinfluss soll hierbei anhand des Grades der Individualisierbarkeit formuliertwerden. Unter dem Individualisierungsgrad aus Kundensicht wird dabei beschrieben, wel-chen Spielraum dem Kunde zur Gestaltung und Anpassung des Produktes entsprechendseiner Bedürfnisse gegeben wird. In dieser auf den Prozess der Komponentenzusammen-stellung fokussierten Kategorisierung erfolgt eine Unterteilung nach:

• anbieterorientierten,

• kundenzentrierten und

• kundenorientierten Produkten.

Anbieterorientiert wird ein Produkt genau dann bezeichnet, wenn der Kunde keine Mög-lichkeit zur Anpassung und Gestaltung des Produktes hat. Eine Individualisierung istbei dieser Produktart demzufolge komplett ausgeschlossen. Das Gegenteil dazu stellen diekundenorientierten Produkte dar. Bei dieser Art ist es dem Kunde möglich, das Produktauf seine Bedürfnisse frei zu gestalten und Anpassungen vorzunehmen. In diesem Fall liegtalso ein ausgereizter Individualisierungsgrad vor. Die kundenzentrierten Produkte sind da-gegen bezogen auf den Gestaltungs- und Anpassungsspielraum begrenzt. Es liegt folglichein beschränkter Individualisierungsgrad vor.Ein gänzlich anderer und grundlegender Ansatz zur Kategorisierung der Produktartenfolgt in Anlehnung an [DS05]. Hierbei können Produkte wie in Abbildung 2.2 dargestelltklassifiziert werden.Hinter der Verfügbarkeit verbirgt sich dabei die Unterscheidung von freien und knappenProdukten. Unter einem freien Produkt versteht man ein Produkt, welches für jedermannverfügbar ist und keiner Gegenleistung bedarf. Ein Beispiel für ein freies Produkt ist dieLuft zum Atmen. Generell gilt, dass freie Produkte keine direkte Rolle in Form eines Er-gebnisses der Zusammenstellung von Komponenten spielen. Knappe Produkte hingegenerfordern in der Regel eine Gegenleistung, die oftmals in Form von Geld geleistet werden


Produkt

Freies ProduktKnappes

Produkt

VerfügbarkeitProdukt zum

Konsum

Investitions-

produkt

Ver

wen

du

ng

Gebrauchs-

produkt

Verbrauchs-

produkt

Wiederverwendbarkeit

Materielles

Produkt

Immaterielles

ProduktB

eschaffen

heit

Abbildung 2.2: Klassifizierung der Produktarten nach Domschke

muss, und werden teilweise mittels der Komponentenzusammenstellung individuell nachKundenwunsch hergestellt. Als Beispiel hierfür wäre das Auto zu nennen. Eine weitereKategorie nach [DS05] ist die Verwendung eines Produktes. Hierunter versteht man dieEinteilung in Produkte zum Konsum und Investitionsprodukte. Produkte zum Konsumdienen unmittelbar der Bedürfnisbefriedigung der Konsumenten (z. B. Nahrungsmittel).Investitionsprodukte werden zur Herstellung von Produkten zum Konsum benötigt unddienen daher nur mittelbar der Bedürfnisbefriedigung. Ein Beispiel hierfür ist eine Schrau-be. Bezogen auf die Kategorie der Wiederverwendbarkeit werden Produkte in Gebrauchs-und Verbrauchsprodukte unterschieden. Ein Gebrauchsprodukt eignet sich zum wieder-holten Einsatz und über einen längeren Zeitraum hinweg in der Herstellung oder zumKonsum. Als Beispiel sei eine Waschmaschine genannt. Verbrauchsprodukte sind dagegennur einmal einsetzbar (z. B. Kraftstoff). Die Kategorie der Beschaffenheit unterteilt Pro-dukte in materielle und immaterielle. Diesen beiden Arten widmen sich die folgenden zweiAbschnitte genauer.

Darüber hinaus gibt es eine Vielzahl an weiteren hier nicht weiter vertieften Kategori-en, mit denen Produkte unterteilt werden können, z. B. nach dem Nachfrageverhalten,nach der Art der Informationsasymmetrie, nach der Möglichkeit des Transports, nachder Rivalität im Konsum oder nach dem Ergebnis im Herstellungsprozess (Endprodukte,Zwischenprodukte und Abfallprodukte).

2.1.3.1 Materielle Produkte

Materielle Produkte werden in der Regel auch als Sachprodukte oder Waren bezeichnet.Beispiele für materielle Produkte sind Autos, Häuser oder Kaffeelöffel. Oftmals werden inwissenschaftlichen Abhandlungen über den Prozess der Komponentenzusammenstellungvorrangig materielle Produkte betrachtet. Das liegt zum einen daran, dass die Rolle dererin der Vergangenheit vermutlich eine größere war als sie in der Zukunft im Vergleich zur


Bedeutung der immateriellen Produkte sein wird. Die Ursache hierfür lässt sich mittelsder Drei-Sektoren-Hypothese von Fisher und Clark erklären. Diese besagt, dass der Sek-tor der Rohstoffverarbeitung, in diesem Falle der Sekundärsektor, an Bedeutung verliert,während der Sektor der Dienstleistung, der Teritiärsektor, stark zunehmend an Bedeutunggewinnt [AWA05]. Die daraus ableitbare Folge der Zunahme von immateriellen Produk-ten impliziert die Notwendigkeit einer Individualisierung der Dienstleistungen analog derIndividualisierbarkeit der materiellen Produkte.

2.1.3.2 Immaterielle Produkte

Unter immateriellen Produkte versteht man grundsätzlich alle Produkte, die nicht denmateriellen Produkten anzurechnen sind. Enger formuliert bedeutet dies, dass immate-rielle Produkte Dienstleistungen darstellen, aber auch reine Informationen, Rechte oderandere immaterielle Werte (z. B. Firmenimage oder Markenname) [DS05]. Es sei hierbeiangemerkt, dass diese Arbeit ausdrücklich nicht nur die materiellen Produkte in Bezug aufdie Komponentenzusammenstellung betrachtet, sondern eben auch immaterielle ProdukteBestandteil der Überlegungen sind.

2.1.4 Typen der Produktfertigung

Materielle Produkte können auf ganz unterschiedliche Art und Weise hergestellt werden.Jeder Typ gibt dabei Auskunft über wichtige Merkmale in Bezug auf eine mögliche Nut-zung im Rahmen des Prozesses der Komponentenzusammenstellung, der im Folgendenauch als Produktkonfiguration (siehe Abschnitt 2.2) bezeichnet wird. Darunter ist vorallem der Flexibilitätsgrad eines Produktes bei einem bestimmten Fertigungstyp zu ver-stehen. Der Fokus liegt hierbei auf den folgenden zwei Kriterien, nach denen die Produkt-fertigung typisiert werden kann:

• Typisierung nach dem Absatzmarkt und

• Typisierung nach der Individualität und Stückzahl.

2.1.4.1 Typisierung nach dem Absatzmarkt

Nach [GT09] unterscheidet man zwischen der Kundenauftragsfertigung, der Lagerfertigungund der auftragsbezogenen Fertigstellung.Bei der Kundenauftragsfertigung, die auch als „Make to Order“ (MTO) bezeichnet wird,gibt es eine Reihe vorhandener Komponenten, die für die Fertigung des Produktes zurVerfügung stehen. Nach der Benennung der Zusammensetzung der Komponenten erfolgtdie Fertigstellung des Produktes nach dem geäußerten Kundenwunsch. Im Anschluss daranerfolgt die Übergabe des Produktes an den Kunden. Zur Veranschaulichung dient dieAbbildung 2.3.Im Unterschied dazu ist bei der Lagerfertigung keine direkte Einbeziehung des Kunden-wunsches vorgesehen. Hier erfolgt ausgehend von der Verfügbarkeit bestimmter Kompo-nenten die Fertigung unterschiedlicher Varianten eines Produktes in einer vorher definier-ten Menge. Die Produkte werden im Anschluss gelagert. Nach Eingang einer Kunden-bestellung erfolgt die Übergabe des Produktes an den Kunden. Die Lagerfertigung wird


Start

Bereitstellung

Teilkompo-

nenten

Zusammen-

setzungHerstellung

Übergabe an

KundeEnde

Kunden-

bestellung

Produkt

Abbildung 2.3: Kundenauftragsfertigung in Anlehnung an [GT09]

auch als „Make to Stock“ (MTS) bezeichnet. Auch hier soll die Abbildung 2.4 zur Ver-anschaulichung dienen.

Start

Bereitstellung

Teilkompo-

nenten

Zusammen-

setzungHerstellung

Übergabe an

KundeEnde

Kunden-

bestellung

Produkt

Abbildung 2.4: Lagerfertigung in Anlehnung an [GT09]

Der dritte absatzmarktbezogene Fertigungstyp wird als auftragsbezogene Fertigstellungoder auch als „Assemble to Order“ (ATO) bezeichnet. Generell ist der Ablauf der Fer-tigstellung identisch mit der Lagerfertigung. Der einzige Unterschied ist im Zeitpunkt dereigentlichen Fertigstellung zu finden. Der Kunde wählt aus einer Menge von Variantendas entsprechende Produkt aus und erst nach dem Eingang der Kundenbestellung erfolgtdie Fertigung des Produktes und im Anschluss daran die Übergabe desselben (siehe dazuAbbildung 2.5). Es findet bei diesem Fertigungstyp demnach keine Lagerhaltung desEndproduktes statt.

Start

Bereitstellung

Teilkompo-

nenten

Zusammen-

setzungHerstellung

Übergabe an

KundeEnde

Kunden-

bestellung

Produkt

Abbildung 2.5: Auftragsbezogene Fertigstellung in Anlehnung an [GT09]

2.1.4.2 Typisierung nach der Individualität und Stückzahl

Betrachtet man den Grad der Individualität und die Stückzahl der Produkte, so kann mandie Produktfertigung unterscheiden in

• Einzelfertigung und

• Mehrfachfertigung.


Am Ende des Abschnittes dient die Tabelle 2.1 zum Vergleich der verschiedenen zurMehrfachfertigung zuzuordnenden Fertigungstypen.

Auftrags- und Einzelfertigung

Die Einzelfertigung, die auch als Auftragsfertigung bezeichnet werden kann, hat die ein-malige Herstellung eines Einzelstückes, sinngemäß eines Unikates, zum Ziel. Sie wird in derRegel auftragsbezogen eingesetzt und zeichnet sich durch den hohen Grad an Individualitätgegenüber dem Kundenwunsch aus. Dieser Fertigungstyp ist für die Produktkonfigurationnicht geeignet, da ein zu hoher Individualisierungsgrad vorliegt. Hinzu kommt, dass beider Eignung für die Produktkonfiguration das wichtige Merkmal des Unikates ad actagelegt werden müsste, was im Widerspruch zum Ziel der Auftrags- und Einzelfertigungsteht. Weitere Gründe sind auch in den Nachteilen der Auftrags- und Einzelfertigung zufinden; diese liegen in den hohen Fertigungskosten pro Produkt und dem sehr niedrigenAutomatisierungsgrad der Fertigung. Zudem müssen universelle Produktionsanlagen vor-handen sein. Ein Beispiel für diesen Fertigungstyp ist die Herstellung des Segelschulschiffes„Gorch Fock“1 der Deutschen Marine.

Serienfertigung

Die Serienfertigung ist der Mehrfachfertigung zuzuordnen. Sie hat die Herstellung von Pro-dukten mit unterschiedlichen Stückzahlen als Aufgabe. Man unterscheidet zwischen Klein-und Großserien. Die Fertigung findet dabei auf identischen Produktionsanlagen statt. Zwi-schen den verschiedenen Serien eines Produktes kann es zu geringfügigen Abweichungen inder Zusammensetzung der Werkstoffe kommen. Die Zusammensetzung der Komponentenunterscheidet sich jedoch nicht. Die Fertigungskosten erreichen im Vergleich zur Einzelfer-tigung ein niedriges Niveau, sind aber im Vergleich zur Massenfertigung höher einzuord-nen. Die Serienfertigung weist eine begrenzte Flexibilität auf, der Automatisierungsgradbefindet sich nach [Abe04] im mittleren Niveau. Die Eignung für die Produktkonfigurati-on ist nicht gegeben. Nach [Sch02] ist „Chargenfertigung“ eine Alternativbezeichnung zurSerienfertigung. Ein Beispiel für die Serienfertigung ist in der Herstellung von Autoreifenzu finden.

Variantenfertigung

Die ebenfalls der Mehrfachfertigung zuzuordnende Variantenfertigung steht für eine Ferti-gung verschiedener Produktvarianten in unterschiedlicher Stückzahl. Sie ist auch unter derBezeichnung der Variantenproduktion bekannt. Der Unterschied zwischen den einzelnenFertigungsmengen liegt in der Zusammensetzung oder in den Eigenschaften der Produkt-komponenten. Das Ziel dieser Fertigung ist also das Erreichen einer Variantenvielfalt.In Bezug auf die Eignung in der Produktkonfiguration gibt es zwei unterschiedliche Be-trachtungsweisen, die sich im Zeitpunkt der Fertigung des zusammengestellten Produktesunterscheiden. Erfolgt die individuelle Zusammenstellung des Produktes durch den Kun-den im Vorfeld der Fertigung, so wird die Variantenfertigung für die Produktkonfigurationals geeignet angesehen. Wenn jedoch erst nach der Fertigung die Wahl einer Variante er-folgt, so hat der Kunde demnach keinen direkten Einfluss auf die Zusammenstellung des

1http://www.gorchfock.de/


Produktes. In diesem Fall wird die Variantenfertigung in Bezug auf die Produktkonfigura-tion als nicht geeignet angesehen. Als Beispiel sei an dieser Stelle die kundenindividuelleFertigung von T-Shirts in unterschiedlicher Variation genannt.

Massenfertigung

Bei der Massenfertigung, die die höchste Ausprägung der Mehrfachfertigung darstellt,werden Produkte in sehr hoher Stückzahl gefertigt. Die Fertigung erfolgt dabei in derfortlaufenden Wiederholung eines festgelegten Prozesses auf voreingestellten Produktions-anlagen. Die Fertigungskosten pro Produkt sind hier am geringsten. Ein weiterer Vorteilliegt im hohen Automatisierungsgrad des Fertigungsprozesses. Der Nachteil dieses Typsliegt in der fehlenden Flexibilität in Bezug auf Kundenwünsche. Für die Produktkonfi-guration ist dieser Fertigungstyp daher nicht geeignet. Als Beispiele seien hierfür Zuckeroder Heizöl genannt.

Kundenindividuelle Mehrfachfertigung

Bei der Betrachtung der kundenindividuellen Mehrfachfertigung muss an dieser Stelleerwähnt werden, dass diese im Rahmen der Arbeit als Synonym für die kundenindivi-duelle Massenfertigung als auch für die kundenindividuelle Serienfertigung Anwendungfindet. Der Grund liegt in der Betrachtung der unterschiedlichen Marktgrößen. So sprichtman bei diesem Fertigungstyp im Bereich der Textil- oder Automobilindustrie von derkundenindividuellen Massenfertigung, die auch als „Mass “ bekannt ist, im B2B-Bereichaufgrund der geringeren Marktteilnehmer und damit geringeren Anzahl von Produktab-nehmern von der kundenindividuellen Serienfertigung [Wüp00]. Um eine Verwechslung derBegrifflichkeiten zu vermeiden, wird dieser Fertigungstyp fortan als „kundenindividuelleMehrfachfertigung“ bezeichnet.Dieser Fertigungstyp, welcher oftmals eher als Fertigungs- oder Produktionskonzept be-zeichnet wird, versucht die Vorteile der Massenproduktion und einen hohen Grad an In-dividualität in Bezug auf den Kundenwunsch zu vereinen [RP03]. Das Ziel ist also diemöglichst preiswerte Produktion einer großen Anzahl von individuell ausgerichteten Pro-dukten durch die Nutzung von „Wiederverwendungs- und Synergieeffekten“ [Lie08]. Dabeiwird dem Kunden die Möglichkeit gegeben, vorgegebene Merkmale eines Produktes bzw.die Zusammensetzung der Produktkomponenten in begrenztem Maße zu bestimmen. Einwesentlicher Unterschied zum zweiten Typ der Variantenfertigung ist im Zeitpunkt der Fer-tigung zu finden: „Im Gegensatz zur Variantenproduktion wird bei der Mass Customizationein Produkt erst produziert, nachdem der Kunde die Produktbestandteile individuell zu-sammengestellt hat“ [HK08].Eine Weiterentwicklung dieses Konzeptes findet sich in der „Open Innovation“ [Bar08].Hier hat der Kunde bereits im Entstehungsprozess des Produktes mittelbaren Einfluss.Die kundenindividuelle Mehrfachfertigung ist für die Produktkonfiguration gut geeignet.

2.1.5 Prozess der Produktentstehung

Bis ein Produkt in seiner finalen Zusammensetzung in die Herstellung geht und im An-schluss an den Kunden übergeben wird, durchläuft es eine Reihe verschiedener Bereiche,


Merkmal /Fertigungstyp Ei

nzel-b

zw.

Auftrag

sfertigun

g

Serie

nfertig

ung

Varia

nten

fertigun

g

Massenfertig

ung

kund

enindividu

elle

Meh

rfachfertigun

g

Stückzahl Einzelstücke Klein- und Großserien o ++ oProduktvorgabe ao po, ao po, ao po po, aoFertigungskosten/Stück ++ o o −− −

Flexibilität ++ o o −− +

Automatisierungsgrad −− o o ++ +

Produktkonfiguration × × ✓* × ✓

Legende:ao: auftragsorientiert ++: sehr hochpo: programmorientiert (Hersteller) +: hoch✓: ja o: mittel/durchschnittlich×: nein −: gering/niedrig*: abhängig von der Definition −−: sehr gering/niedrig

Tabelle 2.1: Vergleich der Fertigungstypen in Anlehnung an [Abe04]

die im Folgenden dargestellt werden sollen. Auch gibt es Unterschiede in der Herstel-lung materieller und immaterieller Produkte. Im späteren Verlauf der Arbeit werden diehier dargestellten Bereiche für die Betrachtung der Integration eines Produktkonfiguratorswieder aufgegriffen.Der Produktentstehungsprozess (PEP) ist als Bestandteil des Produktlebenszyklus an-zusehen [ES08]. Letzterer wird verstanden als „ein theoretisches, abstrahierendes Modellzur zeitlichen Einteilung der Lebensphasen von Produkten“ (im Grunde also von der Ideeeines Produktes bis zu dessen Entsorgung). Die Notwendigkeit dieses Aufzeigens liegt inder Gewinnung von Informationen über den „Nutzen eines Produktes über die einzelnenLebensphasen“ hinweg, um daraus „Entscheidungen hinsichtlich der Produktentwicklungtreffen zu können“ [Sta09]. Zur Betrachtung der einzelnen Abschnitte des Produktlebens-zyklus eignen sich zwei Konzepte: das der Absatzentwicklung und das der Tätigkeiten.

2.1.5.1 Konzept der Absatzentwicklung

Zingel unterteilt im Sinne des Konzeptes der Absatzentwicklung den Produktlebenszyklusin die Einführungsphase, Phase des schnellen Wachstums, Reifephase, Sättigungsphaseund letztlich die Phase der Degeneration (siehe dazu die Abbildung 2.6) [Zin03].Der zeitlich gesehen kürzeste, aber dennoch sehr entscheidende Abschnitt entspricht derEinführungsphase. In dieser wird das Produkt auf den Absatzmarkt gebracht und dempotentiellen Kunden bekannt gemacht. Hierfür werden zahlreiche verkaufsfördernde Maß-


1 2 3 4 5

Zeit

Um

satz

/ V

erk

au

fsza

hl

Abbildung 2.6: Phasen des Produktlebenszyklus nach Zingel

nahmen eingesetzt (z. B. Werbung oder eine aggressive Preispolitik). Charakteristisch fürdiese Phase ist das Auftreten von Kaufwiderständen, da am Anfang die vorhandene Skepsisdes Kunden gegenüber dem neuen Produkt der positiven Kaufentscheidung entgegenwirkt.Das Ergebnis dieser Phase liegt in der Entscheidung darüber, ob das Produkt eine Chanceauf dem Absatzmarkt hat oder nicht. Bei positivem Ausgang der Einführungsphase folgtdie Phase des schnellen Wachstums. Das Produkt ist auf dem Absatzmarkt bekannt unddas eigene Wachstum generiert sich nun bereits ohne die direkte Einwirkung von verkaufs-fördernden Maßnahmen. Auf diese wird logischerweise dennoch nicht verzichtet, da siesich als Wachstumsbeschleuniger eignen. Einen höheren Stellenwert erfährt hingegen diePreispolitik, da die Marktkonkurrenten auf das neue Produkt reagieren und es somit zuneuen Konkurrenzsituationen auf dem Absatzmarkt kommt.

Die dritte Phase ist unter der Bezeichnung Reifephase bekannt und gilt oftmals als profita-belster Lebensabschnitt eines Produktes, weshalb auch die zeitliche Streckung das Haupt-ziel dieser Phase ist. Ein Produkt gilt dann als gereift, wenn das Wachstum stagniert unddas Produkt nicht mehr als Neuigkeit, sondern vielmehr als ein notwendig zu besitzen-des „Pflichtprodukt“ angesehen wird. Im weiteren Fortlauf der Produktexistenz kommtes zu einer Situation, bei der das Wachstum seinen Nullpunkt erfährt. Dies ist genaudann der Fall, wenn für das Produkt keine weiteren Konsumenten zu erschließen sind.Es gilt folglich der Zustand der Nachfragesättigung, weshalb dieser Lebensabschnitt auchals Sättigungsphase bezeichnet wird. Um dennoch den Absatz nicht gänzlich einbrechenzu lassen erfolgen ab dieser Phase sogenannte verkaufserhaltende Maßnahmen, wie z. B.Preissenkungen. Den Abschluss des Produktlebenszyklus nach Zingel bildet die Phaseder Degeneration. Das Wachstum erfährt hier eine Kehrtwende, d. h. der Absatz des Pro-duktes ist rückläufig, welches zur Folge hat, dass das Produkt in absehbarer Zeit nichtmehr auf dem Absatzmarkt existiert. Ist dieser Punkt erreicht, kann sich entweder dieAbschaffung oder die Neueinführung des Produktes anschließen. Zingel spricht hierbeivon der Eliminierung oder dem Relaunch des Produktes.


2.1.5.2 Konzept der Tätigkeiten

Während das soeben vorgestellte Konzept nur den Lebensverlauf des Produktes bezo-gen auf den Absatzmarkt betrachtet, liegt dem im Fortlauf vorzustellenden Konzept derTätigkeiten ein ganzheitlicher Ansatz zugrunde. Hiermit ist im Wesentlichen die Pha-senaufteilung, wie in Abbildung 2.7 schematisch dargestellt, gemeint. Unterhalb derPhasenbezeichnung findet man die dazugehörigen Tätigkeiten.

AnforderungenProdukt-

planungEntwicklung

Prozess-

planungFertigung Betrieb Recycling

Sammeln der

Anforderungen

Programm-/

Portfolioplanung

Projektplan,

Team- & Budget-

bestimmung

Anforderungs-

bestimmung

Methodik

Konzeption

Mechanische

Konstruktion

Elektrische

Konstruktion

Elektronische

Konstruktion

Software-

konzeption

Simulation

DMU/PMU

Testen

Dokumentation

Prozessplanung

Werkzeugdesign

Herstellungs-

ressourcen-

festlegung

Einkauf

Simulation/

Testen

Herstellung

Zusammenbau

Qualitäts-

absicherung

Distribution

Service

Wartung &

Revision

Recycling

Produktidee

Abbildung 2.7: Phasen des Produktlebenszyklus in Anlehnung an [ES08]

Der eigentliche Prozess der Produktentstehung umfasst nach Eigner und Stelzer sinnge-mäß die Phasen von der Produktplanung bis hin zum Betrieb. Die Gewichte der einzelnenBereiche sind einerseits abhängig von der jeweiligen Charakteristik des Produktes (z. B.gibt es Unterschiede im Produktentstehungsprozess zwischen materiellen und immateriel-len Produkten) oder externen Einflussfaktoren (z. B. Gesetzgebung), andererseits ergebensich aber auch Änderungen an den Gewichten durch die globale Veränderung des gesam-ten Absatzmarktes. Dieser Wandlungsprozess führte zu einer Reihe von Verschiebungenunter den Phasen im gesamten Produktentstehungsprozess. Eine bildliche Anschauungderartiger Verschiebungen ist in der Abbildung 2.8 zu finden.

Zeit bis zur Fertigung

Produkt-

entwicklung

Produktions-

entwicklung

Fertigung


Produkt-

entwicklung

Produktions-

entwicklung

Fertigung


PE1

PP1

Fertigung

PE2

PE4 PE3

PP2

PP3

PP4

Serial Engineering (1985 – 1995)

PE: Produktentwicklung

PP: Produktionsfertigung

Simultaneous Engineering (1995 – 2005) Cross Enterprise Engineering ( > 2005)

Abbildung 2.8: Veränderungen der Produktentstehungsmethoden in Anlehnung an [ES08]

Während anfangs eine serielle Abfolge und in der Weiterentwicklung dazu eine simultaneAbfolge (mit teilweise zeitlicher Überlappung) der relevanten Stufen des Produktlebenszy-klus gegenwärtig war, ist der Bereich des Cross Enterprise Engineering vor allem durch die


direkte und zeitlich überlappende Verknüpfung unterschiedlicher Stufen gekennzeichnet.Der gestiegene Anspruch des Kunden an das Produkt und die Veränderungen auf dem Ab-satzmarkt führen hierbei zu einer „mehrdimensionalen Zusammenarbeit und Kooperationinnerhalb des Unternehmens“, insbesondere aber auch zu einer zunehmenden Vernetzungder Kooperationspartner (z. B. Zulieferer oder Subunternehmen) und der bereits erwähn-ten fortschreitenden Verzahnung der einzelnen Phasen des Produktentstehungsprozesses.

2.2 Produktkonfiguratoren

Durch die kundenindividuelle Zusammenstellung seiner Komponenten erfährt ein Produktim Sinne des Produktlebenszyklus (siehe dazu Abschnitt 2.1.5) eine besondere Aufwertung.Ein Werkzeug zur Realisierung dieser Möglichkeit stellen Produktkonfiguratoren dar. Ausdiesem Grund befasst sich dieser Abschnitt mit der Begriffsklärung, den Einsatzbereichenund den Voraussetzungen für den Einsatz von Produkten in der Konfiguration. Es wer-den zudem grundlegende Anforderungen und zentrale Nutzenargumente aus Kunden- undAnbietersicht aufgezeigt. Der Abschnitt schließt mit der Vorstellung eines für Produkt-konfiguratoren relevanten Architekturmusters und dem Blick auf Anwendungsbeispieleaus drei unterschiedlichen Wirtschaftszweigen.

2.2.1 Definition

Für den Begriff des Produktkonfigurators gibt es keine einheitliche Definition. Vielmehrfindet man in der Fachliteratur eine Vielzahl an Begriffserklärungen und Deutungen. Dazuenthält diese Arbeit im Anhang A eine Sammlung derartiger Formulierungen.Als Komposition betrachtet, setzt sich der Begriff aus den zwei Substantiven Produkt undKonfigurator zusammen. Zweiterer stellt eine Ableitung des Verbs konfigurieren (lat. con-figuratio) dar. Als Synonym hierfür werden beispielsweise die Verben „einrichten“, „ein-stellen“, „zusammenstellen“, „verknüpfen“, „anordnen“ oder „gestalten“ verwendet.Im Folgenden wird der Begriff des Produktkonfigurators im Kontext zweier wesentlicherHerausforderungen, im Grunde der steigenden Marktkonkurrenz einerseits und der Er-höhung der Produktindividualität andererseits, betrachtet. Im Laufe der fortschreitendenGlobalisierung und damit auch im Zusammenhang mit der Erschließung neuer Absatz-märkte hat sich die Konkurrenzsituation von Unternehmen im gesamten Weltwirtschafts-system erheblich zugespitzt. Auch gerade deswegen sahen sich die Unternehmen in Teilengezwungen, die eigenen Produktlinien dahingehend anzupassen, dass unter anderem mög-lichst markante positive Unterscheidungsmerkmale im Vergleich zu Marktkonkurrentenfür den Kunden sichtbar wurden. Derartige Merkmale sind z. B. optional wählbare Kom-ponenten oder eine kundenbezogene Farbgestaltung des Produktes. Eine Möglichkeit hier-zu bestand und besteht in der Individualisierung der Produkte, um dadurch in gleicherWeise auch dem wachsenden „Kundenwunsch nach Individualität bei gleichzeitig effek-tiv sinkenden Produktionskosten gerecht zu werden“ [Lie08]. Grundlage für die Fertigungder individualisierten Produkte bietet unter anderem die in Abschnitt 2.1.4.2 vorgestelltekundenindividuelle Mehrfachfertigung.Unter einem Produktkonfigurator versteht man in diesem Zusammenhang ein „geeigne-tes Instrument“, dass den „Kunden befähigt, ein gewünschtes Produkt selbstständig zu

2.2. PRODUKTKONFIGURATOREN 19

KundenUnternehmen

(Produktanbieter)

Produkt-

konfigurator als

Bindeglied

Bedürfnis Angebot

kundenindivi-

duelles Produkt

Bedürfnisbefriedigung Absatzsteigerung

Abbildung 2.9: Produktkonfiguratoren als Bindeglied zwischen Kunden und Unternehmen

spezifizieren“ [Pol08]. Dieser kann folglich als ein „Bindeglied zwischen dem Angebot desAnbieters [also des Unternehmens] und den Bedürfnissen der Kunden“ [Göb09] oder auchals „Kommunikationsschnittstelle zum Kunden“ [HK08] angesehen werden (siehe dazuAbbildung 2.9). Die Aufgabe eines Produktkonfigurators formuliert Scheer unter an-derem als das „Zusammensetzen eines Produktes aus vorgegebenen Produktkomponenten[. . . ] und die Selektion inhaltlicher Ausprägungen der Komponenteneigenschaften [. . . ]unter Einhaltung der Konfigurationsregeln“ [Sch06]. In diesem Zusammenhang formuliertLiebisch den Begriff des Baukastenprinzips, nachdem durch einen Produktkonfigurator„nach zuvor gepflegten Regeln [. . . ] die verschiedenen Module bzw. Komponenten zumgewünschten Produkt kombiniert werden“ können [Lie08]. Als Alternativbezeichnungenwerden in der Fachliteratur die Begriffe des Variantenkonfigurators und des Konfigurati-onssystems verwendet.

Auch im Kontext der Unternehmensintegration (siehe dazu Abschnitt 2.3) und der in-formationstechnischen Unterstützung erfahren Produktkonfiguratoren eine zunehmendeBedeutung. Nicht mehr nur die reine Produktkonfiguration steht gegenwärtig im Vor-dergrund, sondern vielmehr auch die lückenlose Verknüpfung der Unternehmensprozesseund die Kopplung verschiedener wirtschaftlicher Planungs- und Informationssysteme, z. B.Enterprise Resource Planning (ERP) oder Customer Relationship Management (CRM).

Die dem Produktkonfigurator zugrunde liegende Aufgabe der Produktkonfiguration kannnach Scheer zwischen der sogenannten traditionellen und kundeninitiierten Produktkon-figuration differenziert werden. Ersteres ist die Produktzusammenstellung ihm zu Folgegenau dann, wenn die Zusammenstellung der Komponenten zu einem Produkt einer nichtinformationstechnisch gestützten Spezifikation bzw. Konfiguration entspricht; die Aus-wahl also auf gedanklichem Wege oder manuell analog erfolgt. Der Gegenpart dazu wirdals kundeninitiierte Produktkonfiguration bezeichnet. Hierbei spricht Scheer von einerinformationstechnisch gestützten Spezifikation des Produktes. Weiterhin lassen sich Pro-duktkonfiguratoren nach zahlreichen Dimensionen klassifizieren, womit sich das Kapitel 3näher befasst.

Um eine weitere Eingrenzung und damit Konkretisierung des Begriffes zu erreichen, bedarfes einer Abgrenzung in Hinblick auf die Begriffe des Produktkatalogs und des Produkt-designwerkzeugs. Ersterer nimmt eine direkte Produktauswahl vor. Das bedeutet, dassdie im Katalog enthaltenen Produkte fest definiert sind und sich damit nicht anpassenlassen [BAKF04]. Der Kunde kann die Produkte und vereinzelte Eigenschaftswerte, wiez. B. Farbe, auswählen und bestellen. Alle bestellbaren Produkte sind in der Regel bereitsproduziert (siehe dazu auch Abschnitt 2.1.4). Den begrifflichen Unterschied zu dem Pro-


duktdesignwerkzeug findet man in der Funktionalitätserweiterung, die genau dann gegebenist, wenn der Kunde die Anzahl, die Kombinationsmöglichkeiten und/oder die inhaltlicheSpezifikation der Komponenten mitbestimmen kann [Sch06]. Bei einem solchen Produkt-designwerkzeug hat der Kunde demnach direkten Einfluss auf die Definition des Produktesund seiner Komponenten (vgl. dazu Abschnitt 2.1.1). Diesen definitorischen Einfluss hatder Kunde bei der Nutzung eines Produktkonfigurators nicht. Aus diesem Grund wirdin dieser Arbeit das Produktdesignwerkzeug nicht zur Gruppe der Produktkonfiguratorengezählt, sondern als ein gesondertes, elementares Werkzeug im Produktentstehungsprozessangesehen.

2.2.2 Einsatzbereiche

Die Spezifizierung und Entwicklung eines Produktkonfigurators steht eng in Abhängigkeitzu dessen Einsatzbereich. So finden sie in der Gegenwart sowohl im Privat- als auch im Ge-schäftskundenbereich Anwendung. Diese Bereiche geben über die Richtung des Transfersvon Produkten und deren Gegenleistung Auskunft und beschreiben somit die wirtschaft-lichen Beziehungen unter den verschiedenen Teilnehmern (siehe dazu Abbildung 2.10).

Verbraucher

(Consumer)

Unternehmen

(Business)

Verwaltung

(Administration)

B2C

B2B

A2BA2C

C2C

Abbildung 2.10: Einsatzbereiche und ihre wirtschaftlichen Beziehungen

Der Bereich der Privatkunden wird umgangssprachlich auch als Endkundenbereich be-zeichnet. Im Englischen findet man hierzu die Bezeichnung „Business-to-Consumer“ (B2C).Das Segment ist gekennzeichnet durch Privatpersonen, den sogenannten Produktabneh-mern bzw. Konsumenten oder Verbrauchern, auf der einen Seite und den Unternehmen alsProduktfertiger bzw. Produktanbieter oder Hersteller auf der anderen Seite. Als Beispielsei der Verkauf von Nahrungsmitteln oder Kleidung genannt.Der Geschäftskundenbereich wird im Englischen als „Business-to-Business“ (B2B) bezeich-net. Hierbei findet man auf beiden Seiten jeweils Unternehmen, die als Produktfertiger oderProduktabnehmer fungieren können (z. B. Zulieferer in der Automobilindustrie).Darüber hinaus gibt es weitere Möglichkeiten zur Beschreibung von wirtschaftlichen Be-ziehungen, wie z. B. A2C („Administration-to-Consumer“, also zwischen der Verwaltungund den Bürgerinnen und Bürgern) oder aber C2C („Consumer-to-Consumer“, also di-rekt zwischen Privatpersonen). Derartige Beziehungsarten sind in dieser Arbeit aber nichtBestandteil der Betrachtung.Unterschiede in Bezug auf die Gestaltung eines Produktkonfigurators gibt es beispielsweisein der Form der visuellen Informationsbereitstellung. So wird im Geschäftskundenbereich


bei Vorliegen von Branchenähnlichkeit auf erklärende Beschreibungen in der Produkt-darstellung verzichtet, da in diesem Falle das notwendige Expertenwissen vorausgesetztwerden kann. Im Gegensatz dazu bedarf es im Privatkundenbereich einer möglichst um-fangreichen Produktbeschreibung, damit aus Sicht des Kunden das Produkt in seiner Cha-rakteristik und Zusammensetzung verstanden werden kann.

2.2.3 Produktbezogene Voraussetzungen

Der Einsatz von Produkten in der Produktkonfiguration ist nicht universell realisierbar.Hiermit ist gemeint, dass die Produktkonfiguration gewisse Voraussetzungen an die zukonfigurierenden Produkte vorgibt, damit diese an die individuellen Bedürfnisse der Kun-den angepasst und hergestellt werden können. Diese Voraussetzungen lassen sich mit demBegriff der Modularisierbarkeit, dem Vorhandensein von konsistenten Abhängigkeitsbe-schreibungen und der gegebenen Herstellung in der Varianten- und kundenindividuellenMehrfachfertigung (siehe hierzu Abschnitt 2.1.4.2) benennen.

Modularisierbarkeit

Trivial betrachtet lässt sich ein Produkt nur dann konfigurieren, wenn es Ansatzstellen fürdie Veränderbarkeit der Zusammensetzung des Produktes gibt. Dies bedeutet, dass wennein Produkt nur aus einer Komponente besteht, es dann nur in den Eigenschaftswerten derKomponente veränderbar ist. Dies wiederum ist jedoch nur dann möglich, wenn überhauptmehrere Wertbelegungsmöglichkeiten für die Komponenteneigenschaften vorliegen.Die Konsequenz aus dieser Feststellung in Hinblick auf die Eignung für die Produktkonfi-guration ist, dass

1. es für mindestens eine Komponenteneigenschaft mehrere Wertbelegungsmöglichkei-ten geben muss,

2. bei Erfüllung von 1.) das Produkt aus mindestens einer Basiskomponente besteht,

3. bei Nichterfüllung von 1.) sich das Produkt aus mindestens einer Basiskomponenteund einer Optionalkomponente zusammensetzt oder aus mindestens zwei Basiskom-ponenten gewählt werden kann.

Diese Forderungen erklären die Notwendigkeit der sogenannten Modularisierung, der de-finitorischen Zerlegung des Produktes in seine Komponenten und Eigenschaften. Ob eineKomponente als Basis-, Optional- oder Implikativkomponente gilt, wird im Rahmen derModularisierung festgeschrieben, so es nicht schon als gegeben vorliegt. In diesem Zu-sammenhang kann man die komponentenbasierte (Punkt 3) von der eigenschaftsbasiertenModularisierbarkeit (Punkt 1 und 2) unterscheiden. Für die Komponentenbegriffe sei andieser Stelle auf den Abschnitt 2.1.1 verwiesen.Im Zuge der Modularisierung eines Produktes erfolgt die „Anpassung der Produktstruk-tur [hier: Produktmodell] nach Markt- und Produktionsgesichtspunkten“ [Wüp00]. Dabeisind die Marktvarianz (äußere Vielfalt) auf der einen sowie die Fertigungsvarianz (in-nere Vielfalt) auf der anderen Seite von entscheidender Bedeutung, da sie den Einflussder Kunden- sowie Fertigungsanforderungen auf die Modularisierung beschreiben. Zu denKundenanforderungen zählt Wüpping die Punkte


• des möglichst hohen Variantenspektrums (also einer möglichst hohen Anzahl vonKombinationsmöglichkeiten der Komponenten und Eigenschaften),

• der individuellen Problemlösungen,

• der kurzen Lieferzeiten und

• einer hohen Qualität des Produktes.

Weitere Anforderungen aus Kundensicht sind in Abschnitt 2.2.4.1 zu finden. Diese sindkaum beeinflussbar, da sie von außerhalb kommen und durch die Kunden bestimmt wer-den. Demgegenüber steht die Fertigungsvarianz (siehe dazu auch die folgende Abbil-dung 2.11). Wüpping zählt hierzu u. a. die Reduktion der Fertigungskosten durch Bil-dung von Basiskomponenten und die Erfüllung der Kundenwünsche durch die Kombinationvon Komponenten.

Marktvarianz

(äußere Vielfalt)

Fertigungsvarianz

(innere Vielfalt)

Kunden-

anforderungen

Fertigungs-

anforderungen

wer

den

abgeb

ild

et i

n

werd

en a

bgeb

ildet in

Modularisierung

hat Einfluss auf

Komponenten und Eigenschaften als definitorische Zerlegung des Produktes

bestimmt

Abbildung 2.11: Einfluss der Markt- und Fertigungsvarianz auf die Modularisierung

Die bereits genannte Produktindividualität wie auch die Produktkomplexität, die aus derKombinierbarkeit der Komponenten resultiert, lassen sich nach Scheer in jeweils dreiGrößen (keine, bedingte und hohe) abstufen. Von keiner Individualität spricht man hier-bei, wenn der Kunde das Produkt in seiner Zusammensetzung nicht anpassen kann. Diebedingte Individualität lässt eine begrenzte Anpassung zu und wenn das Produkt in denmeisten oder gar allen Komponenten und Eigenschaften anpassbar ist, so spricht man voneiner hohen Individualität. Ähnlich verhält es sich mit der Komplexität eines Produktes.Setzt sich das Produkt nur aus einem oder sehr wenigen Bestandteilen zusammen, so liegtkeine Komplexität vor. Kann das Produkt hingegen aus einer Vielzahl von Komponen-ten zusammengestellt und durch zahlreiche Eigenschaftswerte charakterisiert werden, sospricht man von einer hohen Komplexität. Die bedingte Komplexität befindet sich folglichzwischen den soeben erwähnten Komplexitätsstufen. Diese Art der Unterteilung lässt sichmit der in Abschnitt 2.1.3 vorgestellten Kategorisierung der Produktarten nach Scheerin Zusammenhang bringen. Dazu dient die folgende Tabelle 2.2, die den Zusammenhangder drei Produktarten in Bezug auf die Produktindividualität einerseits und die Produkt-komplexität andererseits beschreibt.


Produktindividualität /Produktkomplexität keine bedingte hohekeine kein gering mittelbedingte gering mittel hochhohe mittel hoch sehr hoch

Tabelle 2.2: Kundeneinflusses bei unterschiedlicher Produktindividualität und Produkt-komplexität sowie Einordnung der Kategorisierung der Produktart nach Scheer

Bei der mit . . . hinterlegten Kombination aus Produktindividualität und -komplexitätliegt demnach kein Kundeneinfluss vor. Dies entspricht gleichzeitig der „anbieterorien-tierten“ Produktart. Bei den mit . . . hinterlegten Kombinationen spricht man von der„kundenzentrierten“ Produktart; hier liegt ein begrenzter Kundeneinfluss vor. Die „kun-denorientierte“ Produktart verbirgt sich hinter der mit . . . hinterlegten Kombination,bei der sehr hoher Kundeneinfluss vorliegt.

Konsistente Abhängigkeitsbeschreibungen

Neben der Modularisierung bedarf es auch des Aufstellens konsistenter Abhängigkeitsbe-schreibungen. Erst durch deren Vorhandensein erhält der Produktkonfigurator seine Kom-petenz zur Zusammenstellung von Komponenten und der Auswahl von Eigenschaftswertenentsprechend der gewünschten Semantik.Konsistente Abhängigkeitsbeschreibungen legen hierbei fest, in welcher Beziehung einzelneKomponenten zueinander stehen. So wird z. B. festgelegt

• ob und falls ja, welche Basiskomponenten kombinierbar sind,

• für welche Komponenten in Bezug auf die Basiskomponenten der Charaktertyp „op-tional“ gilt,

• für welche Komponenten in Bezug auf die Basis- und Optionalkomponenten derCharaktertyp „implikativ“ gilt,

• welche Komponenten sich gegenseitig ausschließen und

• welche Wertbelegungsmöglichkeiten für welche Komponenten in den verschiedenenKombinationen zulässig sind.

Derartige Abhängigkeitsbeschreibungen können mit unterschiedlichen Techniken realisiertwerden. Diese bilden eine Dimension zur Klassifizierung von Produktkonfiguratoren undwerden im Kapitel 3 dieser Arbeit betrachtet.Zusammenfassend lässt sich das Ergebnis der Modularisierung und des Aufstellens kon-sistenter Abhängigkeitsbeschreibungen als ein durch den Produktanbieter definierten Lö-sungsraum beschreiben, der alle realisierbaren Komponentenkombinationen bzw. Produkt-konfigurationen umfasst. Der Lösungsraum enthält zudem alle möglichen Eigenschaftswer-te, die die jeweiligen Komponenten annehmen können. Letztlich sind auch die Produktre-geln, also die Abhängigkeitsbeschreibungen, Bestandteil des Lösungsraums [Pol08].


Der Vollständigkeit halber sei an dieser Stelle erwähnt, dass es neben den produktbezo-genen Voraussetzungen eine Reihe weiterer Bedingungen (z. B. technische und logistischeVoraussetzungen) gibt, die für den Einsatz eines Produktkonfigurators erfüllt sein müssen,hier allerdings nicht weiter betrachtet werden.

2.2.4 Anforderungen und Nutzen

Der Nutzen, der durch den Einsatz eines Produktkonfigurators in den unterschiedlichenGeschäftsbereichen erzielt werden kann, ist an die Erfüllung unterschiedlicher Anforde-rungen gebunden. Hierbei gibt es sichtbare Unterschiede in zweierlei Hinsicht: aus Sichtdes Kunden und aus Sicht des Anbieters. Im Folgenden werden grundlegende Anforderun-gen aus [Sch06], [HK08], [Wüp00], [Göb09] und [BAKF04] bezogen auf die Kunden- undAnbietersicht dargelegt, welche in Abbildung 2.12 zusammengefasst dargestellt sind.

AnbietersichtKundensicht

hohe Benutzer-

freundlichkeit

niedrige Latenz

vollständiges

Informationssystem

gültige und konsistente

Problemlösung

Konfigurations-

flexibilität

Sitzungspersistenz

mächtige

Konfigurationssprache

Flexibilität des

Konfigurationswissens

Plausibilitätsprüfung

Ausfallsicherheit

Systemintegration und

Kompatibilität

Analysefähigkeit

Kundenpflege

Wartbarkeit

Vertriebsunterstützung

Abbildung 2.12: Anforderungen an Produktkonfiguratoren

2.2.4.1 Anforderungen aus Kundensicht

Hohe Benutzerfreundlichkeit: Rogoll und Pillar kommen in [RP03] zu der Er-kenntnis, dass der „Erfolg des Online-Vertriebs von komplexen Produkten weniger vonden Produkteigenschaften [abhängt], als vielmehr von dem Werkzeug, das dem Kundendie Produkte verständlich macht“. Die Benutzerfreundlichkeit ist daher einer der entschei-dendsten Faktoren in Hinblick auf den Erfolg des Produktkonfigurators und den Absatzder Produkte. Göbel formuliert in [Göb09] dazu: „Jede noch so gute innovative Funktionist nutzlos, wenn sie vom Kunden nicht bedient werden kann“. Hiermit ist demnach eineintuitive Bedienbarkeit des Produktkonfigurators gemeint. Weiterhin stehen für eine hoheBenutzerfreundlichkeit neben den noch folgenden Anforderungspunkten:

• eine klare, transparente und barrierefreie Struktur des Oberflächendesigns, also dem„Aussehen“ des Produktkonfigurators,

• eine durchgängige und nachvollziehbare Navigation,

• eine gefühlte Erlebbarkeit, d. h. ein Produktkonfigurator ist „mehr“ als nur ein Pro-gramm, die Produktkonfiguration sollte ein angenehmes und zufriedenstellendes Er-lebnis für den Kunden sein [Pol08],


• eine möglichst breite Kompatibilität in Hinblick auf die vom Kunden eingesetztenSysteme und Programme (z. B. Betriebssystem und Browser) und

• eine internationalisierte Darstellung der Informationen (z. B. Mehrsprachigkeit oderDatenkonvention) [Göb09].

Die Wichtigkeit der klaren, transparenten und barrierefreien Struktur des Oberflächende-signs wird auch durch Drews betont, da seiner Erkenntnis nach die Kunden in der Regelnicht in der Lage sind, zwischen Problemen im Produktprogramm und Problemen in derGestaltung des Konfigurators zu differenzieren [HK08].

Vollständiges Informationssystem: Ein Produktkonfigurator muss grundsätzlich inder Lage sein, den Kunden über das Produkt und dessen Komponenten und Eigenschaf-ten umfassend zu informieren. Der Grund hierfür ist trivial: der Kunde kann nicht auf dasExpertenwissen zurückgreifen und möchte dies in der Regel auch nicht, um die Zusammen-hänge, Leistungen und speziellen Charakteristiken des Produktes erahnen oder gar ver-stehen zu können. Auch sollen durch eine möglichst vollständige Informationsdarstellungschlagkräftige Verkaufsargumente über den Produktkonfigurator an den Kunden vermit-telt werden. Zudem erwartet der Kunde eine transparente Darstellung von Informationenbeispielsweise über die Einzelpreise der Komponenten, den Gesamtpreis des konfigurier-ten Produktes oder die Angabe der Lieferzeit [Pol08]. Je vollständiger und glaubhafter derProduktkonfigurator die Informationen vermittelt, desto höher ist die Wahrscheinlichkeitfür den Aufbau, Erhalt und Ausbau einer guten Vertrauensbasis zum Kunden hin, welchesich logischerweise verkaufsfördernd auswirken kann.

Sitzungspersistenz: Es ist in der Regel nicht davon auszugehen, dass sich ein Kundeein Produkt zusammenstellt und dieses sofort bestellt. Vielmehr möchte der Kunde dieMöglichkeit einer späteren Bestellung nutzen. Aus diesem Grund ist es wichtig, dass derProduktkonfigurator das Speichern und das Laden unterschiedlicher Konfigurationen er-möglicht. Sollte also der Kunde einen Konfigurationsvorgang nicht zu Ende führen, wärees von großen Vorteil, wenn der Kunde den angefangenen Konfigurationsvorgang zu einemspäteren Zeitpunkt fortführen kann, ohne dass Informationen über die Konfiguration desKunden verloren gehen [BAKF04].

Gültige und konsistente Problemlösung: Der Kunde erwartet neben der jederzeitvollständigen Informationsdarstellung durch den Produktkonfigurator auch eine Art Hil-festellung in Hinblick auf den Konfigurationsvorgang. Hierfür müssen dem Kunden alleverfügbaren Optionen kommuniziert werden. Drews nennt dieses auch die „technische,funktionale und inhaltliche Zuverlässigkeit“ [HK08]. Im weiteren Verlauf darf der Kun-de zudem Empfehlungen über mögliche Zusammensetzungen erwarten. Dabei spielt diekundenspezifische Relevanz des Vorschlags eine wichtige Rolle. Letztlich verfolgt die Pro-blemlösung durch den Produktkonfigurator das Ziel der Ergebnisorientierung, d. h. einederartige Unterstützung des Kunden, wodurch der Konfigurationsvorgang erfolgreich be-endet und das Produkt bestellt wird.

Konfigurationsflexibilität: Die Entscheidungen, die ein Kunde während des Konfigu-rationsvorgangs trifft, sind nicht in jedem Fall von dauerhafter Natur. Hiermit ist ge-meint, dass ein Kunde durchaus Entscheidungen für die Wahl, Abwahl oder das Auslasseneiner Komponente rückgängig macht, da er es sich anders überlegt hat. Produktkonfi-guratoren müssen demnach in der Lage sein, in einem Konfigurationsvorgang jederzeit


auf eigenschafts- und komponentenspezifisch frühere Zusammenstellungen zurückzukeh-ren. Ein weiterer zur Konfigurationsflexibilität zuzuordnender Punkt ist der Individuali-sierungsgrad des Produktes. Der Kunde verspricht sich von seinem zu konfigurierendenProdukt eine möglichst hohe Vielzahl an Kombinationsmöglichkeiten und will diese nach-vollziehbar „durchprobieren“. Gleichwohl sei an dieser Stelle darauf hingewiesen, dass einederartige Vielfalt auch ihre Grenzen hat. So kommen Iyengar und Lepper in ihrer Stu-die zu der Erkenntnis, dass sich eine zu große Auswahl negativ auf die Kundenmotivationauswirkt [IL00]. Es gilt also an dieser Stelle, eine Balance in der Größe der Vielfalt zufinden. Der Produktkonfigurator muss in jedem Fall aber in der Lage sein, die durch denIndividualisierungsgrad des Produktes vorhandene Komplexität in der Abbildung zu be-herrschen, um den Kunden eine möglichst intuitive Konfiguration zu ermöglichen (sieheauch Benutzerfreundlichkeit).Niedrige Latenz: Reaktions- und Antwortzeiten des Produktkonfigurators sollten nur einMinimum an Zeit benötigen. Das derzeitige für einen Kunden erträgliche Maximum imBereich von eCommerce-Systemen liegt nach einer Studie von Akamai Technologies2 ausdem Jahre 2009 bei etwa zwei Sekunden. Je länger der Kunde bezüglich seiner Aktivitätauf die Reaktion des Produktkonfigurators warten muss, desto unzufriedener wird er unddesto eher bricht er den aktuellen Konfigurationsvorgang ab [Sch06].

2.2.4.2 Anforderungen aus Anbietersicht

Mächtige Konfigurationssprache: Bedingt durch die gegebene Produktindividualitätkann es eine hohe Anzahl an Kombinationsmöglichkeiten in der Zusammensetzung desProduktes geben. Diese Komplexität muss durch die Konfigurationssprache modellierbarsein, um alle Abhängigkeitsbeschreibungen abbilden zu können. Auch in Hinblick auf diePerformance und die Latenz des Produktkonfigurators ist die Konfigurationssprache ent-scheidend, da z. B. für das Vorschlagen von Kombinationsmöglichkeiten ein hoher Berech-nungsaufwand bei vorhandener Produktkomplexität notwendig sein kann. Zudem hat dieQualität der Konfigurationssprache Auswirkungen auf die Bedienbarkeit durch den Anbie-ter. So ist eine mächtige Konfigurationssprache alleine nicht ausreichend, vielmehr muss sieeine intuitive Bedienbarkeit des Produktkonfigurators durch den Anbieter gewährleisten.Dieser zu realisierende Spagat zwischen der maximalen Mächtigkeit und der möglichst in-tuitiven Bedienbarkeit stellt eine besondere Herausforderung für die Konfigurationssprachedar.Plausibilitätsprüfung: Der Kunde erwartet, dass ein konfiguriertes Produkt in jedemFall auch hergestellt werden kann. Aus Sicht des Anbieters muss dieses in Form einerPlausibilitätsprüfung sichergestellt werden. Ein Produkt, welches zwar konfigurierbar ist,aber nicht hergestellt werden kann, würde einerseits einen enormen Vertrauensverlust desKunden zur Folge haben und andererseits die Professionalität des Anbieter infrage stellen.Zusätzlich besteht die Gefahr einer Kostenexplosion, wenn ein Produkt ohne vorherigemaschinelle Plausibilitätsprüfung hergestellt wird, da es hierbei zu Konstruktions- undFertigungsfehlern kommen kann.Flexibilität des Konfigurationswissens: Komponenten ändern sich in ihrer Charakte-ristik und auch die Abhängigkeitsbeschreibungen ändern sich im Laufe der Zeit. In diesemFall ist es zwingend erforderlich, dass der Anbieter das Konfigurationswissen, in diesem

2http://www.akamai.com/


Fall die spezielle Abhängigkeitsbeschreibung, ohne größeren Aufwand ändern kann. Auchdie verteilte Pflege und Speicherung von Konfigurationswissen ist je nach Art des Pro-duktkonfigurators in diesem Zug zu nennen.Systemintegration und Kompatibilität: Die vom Kunden erwarteten Informationenüber Produkte und Komponenten müssen auf manuelle oder automatisierte Verfahrens-weise in das System des Produktkonfigurators integriert werden. Für den automatisiertenZugriff auf Informationen, wie z. B. Einzelpreise oder die Lieferzeit für bestimmte Kompo-nenten, und damit einer Anbindung beispielsweise an das Warenwirtschaftssystem bedarfes entsprechender Schnittstellen oder Programmodule seitens des Produktkonfigurators.Wartbarkeit: Der Produktkonfigurator muss in technischer Hinsicht ohne großen Auf-wand durch den Anbieter wartbar sein, damit der reibungslose Ablauf und die fehlerfreieFunktionalität gewährleistet ist. Sollte eine direkte Wartbarkeit durch den Anbieter ausGründen des Fehlens von Expertenwissen nicht möglich sein, bedarf es in diesem Fall einergeeigneten Infrastruktur, um zeitnah externe Unterstützung zu erhalten.Ausfallsicherheit: Für die (jederzeitige) Verfügbarkeit des Produktkonfigurators mussgewährleistet sein, dass das System, auf welchem sich dessen Programmkomponenten be-finden, redundant ausgelegt ist. Auch in Szenarien, in denen das Konfigurationswissen aufmehreren Speichermedien verteilt gespeichert wird, muss gewährleistet sein, dass auch beieinem Ausfall eines Speichermediums weiterhin das vollständige Konfigurationswissen mitabgerufen werden kann.Kundenpflege: Aus Sicht des Anbieters muss sich ein Produktkonfigurator gerade im Pri-vatkundenbereich zunehmend als Werkzeug zur Kundenpflege eignen. Hierunter verstehtman z. B. die Akquirierung neuer Kunden durch den Erlebbarkeitsfaktor (siehe Anfor-derung aus Kundensicht), die Intensivierung der Kundenbindung, die optimale Beratungder Kunden (durch Erklärungen und Hilfestellungen im Konfigurationsprozess) oder dieVermittlung des Kundenkontaktes an Vertriebsmitarbeiter, falls es das Vertriebskonzeptvorsieht [HK08].Vertriebsunterstützung: Vertriebsmitarbeiter benötigen bei der internen Nutzung inder Regel Informationen über ein Produkt, deren Komponenten, bestimmte Eigenschafts-werte der Komponenten oder z. B. Dokumentationen wie technische Datenblätter. Ausdiesem Grund muss ein Produktkonfigurator auch als Informationssystem für den eigenenVertrieb geeignet sein, z. B. in Form eines rollenbasierten Anzeigens zusätzlicher Vertriebs-informationen.Analysefähigkeit: Im Rahmen des Konfigurationsvorgangs fallen eine Vielzahl an In-formationen über das Verhalten des Kunden an, die in geeigneter Aufbereitung für denAnbieter von hoher Bedeutung sein können. So kann der Anbieter basierend auf derenAuswertung Änderungen an der Produktzusammensetzung vornehmen oder Anpassungenam Produktkonfigurator selber herbeiführen. Aus diesem Grund sollte der Produktkonfi-gurator geeignete Programmmodule enthalten, die zumindest das Aufzeichnen relevanterInformationen für eine spätere, auch extern mögliche Auswertung realisieren.

2.2.4.3 Nutzen

Der Nutzen eines Produktkonfigurators spiegelte sich bereits teilweise an den genanntenAnforderungen wider. Auch hier bedarf es einer differenzierten Betrachtung bezogen aufdie Kunden- und Anbietersicht.


Aus der Kundensicht liegt der Nutzen in der Individualisierbarkeit des Produktes undder Verkürzung des Bestell- und Fertigungsvorgangs. Auf diese Art und Weise kann je-der Kunde ganz individuell sein eigenes Produkt entsprechend seiner Vorstellungen undBudgetmöglichkeiten selbstständig zusammenstellen. Dabei wird er je nach der Qualitätdes Produktkonfigurators während des Konfigurationsvorgangs in ähnlicher Form „be-treut“, als wenn sich ein Vertriebsmitarbeiter der Beratung annimmt. Einen vollständigenErsatz für einen menschlichen Verkäufer kann ein Produktkonfigurator nach gegenwär-tigem Entwicklungsstandard allerdings nicht darstellen. Insbesondere die psychologischeVerkaufsführung und die zwischenmenschlichen Interaktionen verhelfen dem menschlichenVerkäufer zu einer unverzichtbaren Rolle. Weiterhin ist es dem Kunden möglich, bei Nut-zung eines im Internet verfügbaren Produktkonfigurators zu jeder Zeit und in nahezuunbegrenzter Anzahl die Produktkonfiguration vorzunehmen - er ist so also nicht an dieÖffnungszeiten des Anbieters und an den Verkaufsort gebunden.

Aus Sicht des Anbieters lassen sich vor allem strategische Wettbewerbsvorteile durch dieKomplexitätsbewältigung und Reduzierung der Variantenvielfalt im Sinne der Modula-risierung, der Kundenorientierung durch die direkte Umsetzung der Kundenbedürfnisseoder aber durch die Vermittlung des Erlebbarkeitsfaktors erzielen [Sch06]. An dieser Stellesei angemerkt, dass derartige Wettbewerbsvorteile nur solange existieren, wie die Nutzungvon Produktkonfiguratoren in dem entsprechenden Wirtschaftszweig nicht der Normali-tät entspricht. Auch die Formalisierung des Wissens über die Produktzusammensetzungund -abhängigkeiten ist aufgrund der steigenden Individualisierung in der Produktweltvon enormen Nutzen. Zudem sorgt diese Erfassung für eine gewisse Dauerhaftigkeit derInformationen, da sich selbige nicht mehr nur in den Köpfen der Produktdesigner be-finden. Darüber hinaus gibt es zudem in den Bereichen der Produktivität (z. B. durchkundenindividuelle Mehrfachfertigung) und der Kostensenkung (z. B. durch Reduzierungder Vertriebskosten) enorme Vorteile durch die Verwendung von Produktkonfiguratoren.

2.2.5 MVC-Architekturmuster

In diesem Unterabschnitt soll der Blick nunmehr auf die technisch-strukturelle Ebene desProduktkonfigurators gelenkt werden. Bezogen auf die verschiedenen Arten von Anwen-dungsprogrammen lassen sich Produktkonfiguratoren der Gruppe der „Interaktiven Sys-teme“ zuordnen, da bei diesen eine mittelbare Mensch-Computer-Interaktion stattfindet.Die Erklärung hierfür ist trivial: Der Mensch im Sinne des Kunden bzw. Anbieters inter-agiert mit dem Produktkonfigurator, der wiederum als Anwendungsprogramm auf einemComputer ausgeführt wird.

Bei der Entwicklung derartiger Anwendungsprogramme kommen verschiedene Muster zumEinsatz, wie z. B. die Entwurfs- oder Architekturmuster. Letztere bestimmen die grund-legende Organisation und Interaktion zwischen den Komponenten eines Anwendungspro-grammes [Die10]. Buschmann bezeichnet Architekturmuster als Schablonen für konkreteSoftwarearchitekturen, die die systemweiten strukturellen Eigenschaften einer Anwendungspezifizieren und die Architektur der Programmkomponenten beeinflussen [Bus10]. Er un-terteilt sie zudem in die vier Kategorien Chaos zu Struktur (Mud-to-structure), VerteilteSysteme, Interaktive Systeme sowie Adaptive Systeme. Die für einen Produktkonfiguratorrelevante Kategorie der interaktiven Systeme umfasst u. a. das Architekturmuster ModelView Controller (MVC), welches im Folgenden näher betrachtet wird.


Der Ursprung des genannten Architekturmusters liegt im Jahre 1979. Trygve Reens-kaug, der zur damaligen Zeit im Xerox PARC (Xerox Palo Alto Research Center) imUS-amerikanischen Bundesstaat Kalifornien gelegenen Ort namens Palo Alto arbeitete,veröffentliche am 10. Dezember 1979 die definitorische Festlegung der Begrifflichkeiten imRahmen des MVC [Ree79]. Zur damaligen Zeit arbeitete Reenskaug an der Entwicklungder Programmiersprache und zugleich auch Entwicklungsumgebung namens Smalltalk-80[Kay93]. Im Jahre 2003 erfolgte durch ihn eine Erweiterung des MVC-Begriffes [Ree03].

Controller

Model

indirekte Assoziation

direkte Assoziation

ViewView

Abbildung 2.13: Architekturmuster MVC

Das Architekturmuster beschreibt seinem Namen entsprechend die in Abbildung 2.13dargestellten Ebenen Model (Modell), View (Präsentation bzw. Darstellung) und Con-troller (Steuerung bzw. Ablaufsteuerung) [Ros09]. Das Modell umfasst dabei alle darzu-stellenden Anwendungsdaten und je nach Art der Implementierung entsprechende Teileder Geschäftslogik. Die Ebene wird umgangssprachlich auch als Datenmodell-Ebene be-zeichnet. Das Modell bildet eine in sich geschlossene Einheit und ist zudem unabhängigvon der Präsentation der Daten oder dem Interaktionsverhalten des Nutzers. Die Aufga-be der Ebene View liegt in der Darstellung der Anwendungsdaten aus dem Modell. Zueinem Modell kann es hierbei mehrere Views geben. Die Controller-Ebene ist letztlich fürdie Verarbeitung der Daten verantwortlich, welche bei der Interaktion zwischen dem Nut-zer und dem Anwendungsprogramm erzeugt werden. Auch wird die Geschäftslogik dieserEbene zugeordnet, sollte sie nicht bereits Bestandteil des Modells sein. Bezogen auf denProduktkonfigurator lässt sich die folgende Zuordnung nach [Lie09] herstellen, nach derdie Daten über die Produkte, deren Komponenten und Eigenschaften, wie auch die Ab-hängigkeitsbeschreibungen als solche der Modellebene entsprechen. Das Erscheinungsbildund die verschiedenen Konfigurationsmasken, d. h. die Anzeigevariationen der Kombina-tionsmöglichkeiten und alle grafischen Elemente, sind der View-Ebene zuzuordnen. DieAnwendungslogik, die u. a. auch für die technische Umsetzung der Abhängigkeitsbeschrei-bungen zuständig ist, wird hierbei der Controller-Ebene zugeordnet.Der Vorteil dieser Ebenenaufteilung zeigt sich in der Umsetzung durch die Trennung vonAnwendungsdaten, Funktionalität und Darstellung. So ist es z. B. möglich, für ein An-wendungsprogramm zahlreiche Templates zu entwerfen, die das Anwendungsprogramm


bezogen auf verschiedene Interaktionsinhalte oder unterschiedliche Kunden in andererDarstellung erscheinen lassen. Zudem ist der jederzeitige Austausch der Anwendungsda-ten möglich. Diese gegebene Flexibilität impliziert auch Vorteile in der Wartbarkeit desProgramms.

2.2.6 Anwendungsbeispiele

Abschließend sollen in diesem Unterabschnitt drei Anwendungsbeispiele vorgestellt wer-den, um somit einen Blick auf die praktische Relevanz der Produktkonfiguratoren zu wer-fen (siehe dazu auch die Tabelle 2.3). Hierfür werden einführende Informationen zu denAnbietern, der zentralen Aufgabe des Produktkonfigurators und dem eigentlichen Konfi-gurationsvorgang dargelegt.

Merkmal/Konfigurator CREALIS® mymuesli Traiteur Carl18.91™

Haupt-Einsatzbereich B2B B2C B2BWirtschaftszweig universell Nahrungsmittel GastronomieProduktart materiell materiell immateriellProdukt universell Bio-Müsli Catering

Tabelle 2.3: Anwendungsbeispiele für Produktkonfiguratoren im Vergleich

2.2.6.1 CREALIS®

Die Jenaer Firma ORISA Software GmbH bietet im Rahmen ihres Produktportfoliosmit CREALIS® einen Standardkonfigurator für variantenreiche Produkte im Anlagen-,Maschinen- und Fahrzeugbau sowie in der Automatisierungs- und Zulieferindustrie an.ORISA ist ein mittelständisches Unternehmen mit etwa 40 Mitarbeitern und entwickeltseit mehr als 15 Jahren Anwendungsprogramme unter anderem im Bereich der Produkt-und Variantenkonfiguration sowie der Experten- und Wissensmanagementsysteme. Wei-tere Geschäftsfelder sind u. a. die Projektabwicklung und Beratung. Zur Demonstrationder Funktionalität und Leistungsfähigkeit von CREALIS® stellt ORISA3 verschiedeneDEMO-Konfiguratoren zur Verfügung.CREALIS® ist aus den vier Komponenten Collector, Mentor, LCC und CRM aufgebaut.Der Collector wird von ORISA auch als Modellbaukasten bezeichnet, da diese Programm-komponente alle Beschreibungen und Informationen über die Komponenten des Produktesaus den unterschiedlichen Bereichen der Konstruktion, Beschaffung, Fertigung und demVertrieb zusammenführt und verwaltet. Zudem erfolgt im Collector die Festlegung derAbhängigkeitsbeschreibungen. Der Mentor führt den Kunden durch den gesamten Kon-figurationsprozess in Form eines Interviews. Dabei werden dem Kunden schrittweise dieKomponenten erklärt und die Möglichkeiten zur Aus- und Abwahl von diesen angezeigt. Esist zudem vorgesehen, dass die Konfigurationsergebnisse in externe Systeme, wie z. B. PPS-oder ERP-Systeme, exportiert werden können. Vorgenommene Konfigurationen können so-wohl gespeichert als auch geladen werden. Weiterhin ist eine sofortige Angebotserstellungfür das konfigurierte Produkt möglich. Die dritte Komponente LLC steht für „Life Cycle

3http://www.crealis.de


Costing“. Dahinter verbirgt sich die Funktionalität der Wirtschaftlichkeitsberechnung aufder Grundlage von komponentenbasierten Informationen wie z. B. der Materialkosten oderder Reparaturkosten. Die vierte Komponente namens CRM ermöglicht eine vollständigeAbwicklung des gesamten Vertriebsprozesses.

Einer dieser DEMO-Produktkonfiguratoren hat das Ziel der individuellen Konstruktion ei-nes Heißluftballons. Der Aufbau der grafischen Benutzeroberfläche ist in Abbildung 2.14bildlich dargestellt. So verfügt CREALIS® über eine Menüleiste (A), über die man zumeinen die Konfiguration speichern und laden, verwerfen, drucken oder versenden kann. Zu-dem sind Informationen über den Produktkonfigurator abrufbar. Auch per Klick möglichist die Erstellung eines Angebotes für die aktuelle Konfiguration. Darüber hinaus ist eineübersichtliche Navigation (B) zu erkennen, die dem Nutzer in jedem Konfigurationsschrittanzeigt, in welchem Bereich er sich gerade befindet. Im Bereich (C) erfolgt die Anzeige derwählbaren Komponenten und allgemeinen Hinweise. Zwischen den einzelnen Konfigurati-onsschritten kann mittels der im Bereich (D) sichtbaren Schaltknöpfe gewechselt werden.Letztlich informiert der Produktkonfigurator den Nutzer in (E) über den aktuellen Statusder Konfiguration.

Abbildung 2.14: Grafische Benutzeroberfläche des CREALIS® Mentor

Der Konfigurationsvorgang erfolgt im Beispiel des Heißluftballons schrittbasiert. Als erstesmuss der Nutzer in einer Strategieauswahl entscheiden, nach welchem Hauptkriterium dieZusammenstellung erfolgen soll. Es gibt hierbei die Auswahlmöglichkeiten Personenanzahl,Ballontyp sowie Hüllengröße. Abhängig von der getroffenen Entscheidung erfolgt dann dieAuswahl der Eigenschaftswerte, wie z. B. die Hüllengröße oder die Farbe der Ballons. ImAnschluss daran hat der Kunde die Möglichkeit, weitere Optionen auszuwählen oder zu-sätzliches Zubehör zu bestellen. Abschließend erfolgt die Darstellung einer übersichtlichenZusammenfassung der ausgewählten Komponenten und Eigenschaftswerte.


2.2.6.2 MyMuesli Cerealienkonfigurator

Auch im Bereich der Nahrungsmittelindustrie gibt es eine Reihe diverser Produktkon-figuratoren. Dies ergibt Sinn, denn ein aus beliebig vielen Zutaten zusammengesetztesNahrungsmittel eignet sich sehr gut zur Modularisierung. Ein Beispiel aus dieser Bran-che ist der Cerealienkonfigurator4 der Firma mymuesli GmbH aus Passau. Der von dreiStudenten im Jahre 2007 online gestellte Produktkonfigurator ermöglicht die individu-elle Zusammenstellung eines Bio-Müslis. Der Kunde kann hierbei aus über 75 Zutatenauswählen oder ein bereits vordefiniertes Müsli käuflich erwerben.Der Vorgang der Cerealienzusammenstellung ist dabei in drei Hauptschritte unterteilt. Zu-erst erfolgt die Auswahl der sogenannten Müslibasis (z. B. Haferflocken), die man zudemmit zusätzlichen Zutaten, wie z. B. Roggenflocken oder Vollkorn-Cornflakes, verfeinernkann. Sofort nach der Auswahl einer Müslibasis erfolgt durch den Cerealienkonfiguratorein Hinweis, welche Zutaten zur Verfeinerung von anderen Kunden ausgewählt wurden. Imzweiten Schritt kann der Kunde nun etliche Früchte, Nüsse und Kerne oder Extras (z. B.kleine Espresso-Bohnen oder Honigflocken) dem Müsli beigeben. Während der Kundeseine Auswahl vornimmt, werden diesem durch den Konfigurator die aktuellen Nährwert-angaben dargestellt, sodass das Müsli entsprechend eigener Bedürfnisse zusammengestelltwerden kann. Im dritten und letzten Teil des Konfigurationsvorgangs erfolgt die Bestel-lung des zusammengestellten Müslis. Der Cerealienkonfigurator gibt dem Kunden hierbeieinen sehr großen Freiraum in der Zusammenstellung des Müslis, da es nur wenige Abhän-gigkeiten zu beachten gilt, wie z. B. das Vorhandensein einer Müslibasis für die Auswahlvon Verfeinerungszutaten.

2.2.6.3 Traiteur Carl 18.91™ Konfigurator

Der dritte in diesem Unterabschnitt relevante Produktkonfigurator findet seinen Platz imBereich der immateriellen Güter. Konkret geht es um einen Konfigurator zur individuellenZusammenstellung eines Catering-Services für diverse Veranstaltungen. Er wird in dieserArbeit dem Bereich der immateriellen Güter zugerechnet, da vordergründig die genaueCharakteristik der Dienstleistung zusammengestellt wird und die auszuwählenden Gerich-te nur Bestandteil dieser Dienstleistung sind. Angeboten wird der Catering-Konfiguratorvon der Firma Broich Premium Catering GmbH 5 mit Sitz in Düsseldorf. Der Name dervom Konfigurator zu spezifizierenden Dienstleistung setzt sich wie folgt zusammen: DasWort Traiteur kommt aus dem Französischen und bedeutet soviel wie „handeln“ oder„durchführen“. In Frankreich ist ein Traiteur ein traditioneller Kochberuf, der vorwiegendfür den Adel und das Großbürgertum von Bedeutung war. Carl steht für den Namendes Urgroßvater des Patrons Georg W. Broich, der geschäftsführender Gesellschafter desUnternehmens ist. Die Zahl 18.91 repräsentiert das Gründungsjahr der Firma.Der Konfigurationsprozess ist in sechs Auswahlbereiche gegliedert. Im ersten Schritt erfolgtdie Auswahl der Speisen (z. B. Salat, Pasta, Dessert). Diesem schließt sich die Auswahldes Geschirrs und der Getränke an. Im vierten Schritt erfolgt die genaue Spezifizierungdes Catering-Services durch die Selektion eines Servicepaketes. Zudem gibt es die Mög-lichkeit, Mobiliar und Dekoration für die Veranstaltung zu buchen. Letztlich erfolgt diePreisermittlung für die Transportkosten durch Eingabe der Postleitzahl. Zum Abschluss

4http://www.mymuesli.com5http://konfigurator.broich-catering.com

2.3. UNTERNEHMENSINTEGRATION 33

der Konfiguration wird eine übersichtliche Darstellung der ausgewählten Komponentenangezeigt.

2.3 Unternehmensintegration

Über die letzten Dekaden hinweg gab es in der Wirtschaft zwei wesentliche Veränderungen,die die Notwendigkeit der Unternehmensintegration zunehmend in den Vordergrund rückenund dieses Thema daher auch in diesem Abschnitt seine Beachtung findet. Dazu werden derBegriff im Folgenden definiert und verschiedene Sichtweisen sowie grundlegende Ansätzeder Unternehmensintegration vorgestellt.

Eine der angesprochenen Veränderungen ist die in der Vergangenheit innerhalb der Unter-nehmen zunehmend stattgefundene Einrichtung von Plattformen zur Informationsverar-beitung. Oftmals erhielten somit Abteilungen eine bereichszentrale Plattform, die sich fürdie Verarbeitung der abteilungsrelevanten Informationen verantwortlich zeigten. Die Fol-ge war eine Ansammlung unabhängiger Anwendungen einerseits und Informationssystemeandererseits, die beiläufig auch als isolierte Datenverarbeitungseinheiten bezeichnet wer-den [DMMW03]. Es entstand somit im Laufe der Zeit eine Vielzahl an redundanten oderheterogenen Informationen, woraus unterschiedliche Probleme in der Zusammenarbeit ver-schiedener Abteilungen oder im Fortlauf reiner Produktentstehungsprozesse resultierten.Exemplarisch ist hierfür die Notwendigkeit des Datenabgleiches zwischen den Abteilungenzu nennen. Des Weiteren sei an dieser Stelle darauf hingewiesen, dass die Redundanz keinegrundlegend negative, sondern teilweise sogar eine geforderte Eigenschaft darstellt (z. B.im Bereich der Datensicherung). Eine derartige Redundanz ist dann allerdings kontrollier-ter Natur, wovon im Falle der isolierten Datenverarbeitungseinheiten nicht die Rede seinkann.

Die zweite wesentliche Veränderung liegt in der fortschreitenden Ausgliederung von Ar-beitsschritten aus dem Unternehmen bis hin zur kompletten Ausgliederung von gesamtenAbteilungen des Unternehmens (sog. „outsourcing“). Der Vorteil dieses Vorgehens liegt inder Spezialisierung der Arbeitsvorgänge. Während z. B. in der Automobilindustrie anfangsdie Komponenten in Eigenregie gefertigt wurden, erfolgt in der Gegenwart die Fertigungeinzelner Komponenten durch Zulieferbetriebe, die sich hierauf spezialisiert haben. DerNachteil dieser Veränderung liegt zum einen in der teilweise zu konzentrierten Abhängig-keit der Zulieferbetriebe gegenüber dem Auftraggeber, womit eine Instabilität des Wirt-schaftsgefüges einhergeht, unter anderem aber auch im Vorhandensein unterschiedlicherDaten- und Wissensbasen, da Informationen über die Komponenten in den beteiligtenUnternehmen jeweils separat generiert und erfasst werden. Zudem geht durch die Ausglie-derung auch ein Maß an interner Flexibilität verloren.

Damit gegenwärtig und auch in der Zukunft eine reibungslose, effektive und gewinnbrin-gende Zusammenarbeit zwischen den Abteilungen bzw. Unternehmen einerseits und demerfolgreichen Ineinandergreifen der verschiedenen Produktentstehungsprozesse anderer-seits gewährleistet ist, bedarf es der Anwendung der Unternehmensintegration, die imFortlauf auch als Integration bezeichnet wird.


2.3.1 Definition

Der Begriff der Integration entstammt dem lateinischen Wort integrare und bedeutet sinn-gemäß „vervollständigen“. Die Integration kann dabei als die „Wiederherstellung des Gan-zen durch das Verbinden oder Vereinigen logisch zusammengehörender Teile“ verstandenwerden [Kai02]. In diesem Zusammenhang formuliert Kaib die Grundmotivation der In-tegration als die „unbestimmte Hoffnung, dass der Nutzen des Ganzen höher sei als dieSumme des Nutzen seiner Teile“ und definiert die Unternehmensintegration als das un-mittelbare Entgegenwirken der „negativen Folgen der durch Arbeitsteilung und Speziali-sierung herbeigeführten Funktions-, Prozess- und Abteilungsgrenzen“. Bieniek bezeichnetden Integrationsbegriff als „Verknüpfung von Mensch, Aufgabe und Technik zu einer Ein-heit“ [Bie01]. In [Rüh09] wird der Begriff der Unternehmensintegration in Bezug auf denZusammenschluss zweier Unternehmen als Prozess verstanden, in dem, ausgehend vomerwerbenden Unternehmen, über Interaktionen zwischen beiden Unternehmen immateri-elle Fähigkeiten übertragen und materielle Ressourcen effizienter genutzt werden. Nach[DMMW03] gibt die Unternehmensintegration Antworten auf die Frage, wie vorhandene,oftmals autonome Systeme, Komponenten oder Datenbasen fortlaufend genutzt werdenund dabei vorhandene Probleme der Datenheterogenität oder Funktionsüberschneidungder Anwendungsprogramme aufgelöst werden können.

Einen anderen Ansatz der Begriffsklärung ist in [Lin95] zu finden: Linß unterscheidethierbei den Integrationsbegriff in Integrationszustand und Integrationsvorgang. Ersteresbeschreibt, ob und wie Anwendungssysteme mit Organisationen oder anderen Systemenverknüpft sind. Er wird zudem charakterisiert durch den Integrationsgrad und der Inte-grationsform. Der Integrationsvorgang beschreibt die Zusammenführung einzelner Kom-ponenten zu einem Ganzen unter der Anwendung bestimmter Konzepte, die als Integra-tionsansätze bezeichnet und im Abschnitt 2.3.3 näher betrachtet werden. Der eigentlicheVorgang der Integration entspricht im Sinne von Linß dem Übergang von einen in einenanderen Integrationszustand (siehe dazu auch die Abbildung 2.15).

Integrations-

form/ -grad

Integrations-

form/ -grad

Integrations-

form/ -grad

Integrations-

form/ -grad

Integrations-

ansatz

Zustand ZustandVorgang

Abbildung 2.15: Zusammenhang zwischen Integrationszustand und -vorgang nach [Lin95]


2.3.2 Sichtweisen

Die Sinnhaftigkeit und Realisierbarkeit einer Unternehmensintegration lässt sich nach[SWD03] anhand vier verschiedener Sichtweisen erfragen. Diese sind die Geschäftssicht,Prozesssicht, Anwendungssicht und die technische Sicht. Im Folgenden werden die Sicht-weisen in Anlehnung an [SWD03] beschrieben.Unter der Geschäftssicht versteht man im Grunde alle Vorgänge, bei denen eine Wert-schöpfung von materiellen und immateriellen Produkten erfolgt. Durch die bereits imeinleitenden Teil näher beschriebene Ausgliederung werden Vorprodukte bzw. Leistungeneingekauft. So fallen beispielsweise bei jeder Übergabe eines derartigen Vorproduktes odereiner Leistung an das Unternehmen eine Vielzahl an Informationen über das eigentlicheProdukt an, die im Rahmen des Einkaufs übergeben werden. Diese müssen in geeigneterWeise zentral aufbereitet und vorgehalten werden, damit die gewünschten Synergieeffekteeintreten. Der Betrachtungsgegenstand der Geschäftssicht konzentriert sich dabei auf diePunkte, wie die Wertschöpfungskette organisiert ist und welcher Nutzen durch die Inte-grationslösung im Allgemeinen und für das Unternehmen im Speziellen zu erwarten ist.Letzteres bezieht sich oftmals auf die Vermeidung der Mehrfacherfassung von Informatio-nen und der Minimierung von Kostenfaktoren.Im Rahmen der Prozesssicht erfolgt die Beleuchtung der betrieblichen Abläufe. Hiermitsind die einzelnen Prozesse in einem Unternehmen (diese werden als interne Prozesse be-zeichnet) wie auch die Prozesse zu den beteiligten Partnern (externe Prozesse) gemeint,die in einem Zusammenhang mit dem Lebenszyklus der Produkte stehen. Zwischen deninternen und externen Prozessen existieren sogenannte Nahtstellen, über die die Prozes-se miteinander interagieren können. Derartige Nahtstellen entsprechen auch den Ansatz-stellen möglicher Prozessintegrationen. Diese können in beide Richtungen erfolgen, d. h.intern (z. B. werden interne Prozesse in einen internen Hauptprozess des Unternehmensintegriert) wie auch extern (z. B. durch die Integration eines externen Prozesses in dieProzesslandschaft des Unternehmens).Die Beschreibung der Unterstützung der soeben erwähnten Prozesse durch die Informati-onssysteme des Unternehmens steht im Mittelpunkt der Anwendungssicht. Hierbei werdenu. a. die verwendeten Anwendungsprogramme, die zu integrierenden Funktionen und diedurch die Anwendungsprogramme beeinflussten Informationen betrachtet. Konkret gehtes hierbei um Fragen der Sicherheit in Form der Zugriffsberechtigungen, d. h. welcherMitarbeiter des Unternehmens hat Zugriff auf welche Informationen und durch welcheAnwendungsprogramme erfolgt die Verwaltung und Steuerung von internen und externenProzessen. Auch die Frage der Informationsbewegungen im Sinne von synchronen oderasynchronen Vorgängen spielt eine Rolle, wie auch der Formatierungsstandard (u. a. XML(Extensible Markup Language), EDIFACT (Electronic Data Interchange For Adminis-tration, Commerce and Transport), SWIFT (Society for Worldwide Interbank Financi-al Telecommunication) oder CSV (Comma-Separated Values)) oder der Standard für dieVerwaltung von Geschäftsdokumenten (u. a. openTRANS (offener Standard zur Unterstüt-zung des elektronischen Datenaustauschs bei Geschäftstransaktionen), cXML (commerceeXtensible Markup Language), xCBL (XML Common Business Library) oder Idoc (In-termediate document)). Für eben genannte und weiter folgende Abkürzungen existierenerklärende Einträge zum Nachlesen im Abkürzungsverzeichnis.Einen Blick auf die zugrunde liegende technische Architektur und derer Komponenten gibtdie technische Sicht. So werden die Architekturen der Informationssysteme, die eingesetz-


ten Betriebssysteme, die Hard- und Software, die Netzwerktechnologie und die Systemsi-cherheit betrachtet. Hierbei kann die Integration nach dem bereits im Abschnitt 2.2.5 be-schriebenen MVC-Ansatz vorgenommen werden. Auf der View-Ebene entspricht dies densogenannten grafischen Schnittstellen. Exemplarisch seien hier die Verfahren des „ScreenScraping“ und der „Content Syndication“ genannt. Unter dem Begriff des Screen Scrapingversteht man die Integration von Informationen durch das Auslesen über die grafische Dar-stellung auf dem Fremdsystem (d. h. die zu integrierenden Informationen werden bereitsauf einem anderen System dargestellt). Der Begriff der Content Syndication bezeichnetdas Extrahieren von Informationen aus Fremdsystemen, was die Mehrfachverwendung derselben Informationen zur Folge hat. Hinter der Controller-Ebene verbergen sich in der tech-nischen Sicht drei verschiedene Schnittstellen: die funktionsorientierte (z. B. RPC (RemoteProcedure Call) oder RFC (Remote Function Call)), die methodenorientierte (z. B. COM(Component Object Model) oder BAPI (Business Application Programming Interface))und die nachrichtenorientierte Schnittstelle (z. B. MSMQ (Microsoft Message Queuing)).Letztlich beschreibt die Modell-Ebene die Datenintegration in Form der Datenvereinigung,der Replikation oder der einfachen Übermittlung von Informationen zwischen verschiede-nen Anwendungssystemen.

2.3.3 Grundlegende Ansätze

Zur Umsetzung der Unternehmensintegration können unterschiedliche Ansätze als Grund-lage verwendet werden. Diese können nach [SWD03] in interne und externe Integrations-ansätze unterschieden werden. Ein Vertreter für die interne, also unternehmensweite, In-tegration findet sich in der „Enterprise Application Integration“ (EAI). Hierunter verstehtman die „Integration von Anwendungen über unterschiedliche technische und logische In-frastrukturen hinweg“, wobei die Techniken und Prozesse der eingesetzten Software derartmiteinander kombinierbar sind, dass „Geschäftsprozessdaten im Format und Zusammen-hang jederzeit ausgetauscht werden können, ohne dass dabei die Bedeutung der Daten ver-ändert wird bzw. verloren geht“ [Det02]. Aier und Schönherr formulieren die Kernideeder EAI mit der Bereitstellung einer zentralen Plattform, welche Anwendungsprogrammeüber entsprechende, zum Teil vorgefertigte Adapter anbindet. Zur bildhaften Vorstellungdient an dieser Stelle die Abbildung 2.16.

AP1 AP2 AP3 AS1

AS2 AP4 AS3 AS4

Enterprise Application Integration (EAI)

AP: Anwendungsprogramm AS: Anwendungssystem

Abbildung 2.16: Enterprise Application Integration


Ein Vertreter für die externe, also unternehmensübergreifende Integration findet sich inder sogenannten „Business-to-Business Application Integration“ (BBAI). Hierbei gibt esdrei verschiedene Ansätze zur Überbrückung der Unternehmensgrenzen. Der triviale An-satz entspricht der direkten Verknüpfung zweier Anwendungssysteme, welche auch als 1:1-Verknüpfung bezeichnet wird. Eine Erweiterung stellt der als 1:n-Verknüpfung bezeichneteAnsatz dar. Dieser eignet sich vor allem dann, wenn mehrere Anwendungssysteme auf ei-ne identische Informationsquelle zugreifen. Von einem intermediären Ansatz spricht mangenau dann, wenn zwischen einer Vielzahl von Anwendungssystemen ein zentrales Sys-tem, welches auch als Intermediär bezeichnet wird, zwischengelagert ist (siehe dazu dieAbbildung 2.17).

U1

U2

U1

U2 U3 U4

U2

U4 U5 U6

U1 U3

Intermediär

1:1 Verknüpfung 1:n Verknüpfung intermediäre Verknüpfung

: Verknüpfungseinheit : UnternehmenUn

Abbildung 2.17: Business-to-Business Application Integration in Anlehnung an [SWD03]

Ein weiterer Ansatz der externen Unternehmensintegration findet sich im Bereich derService-orientierten Architektur (SOA). Die SOA wird in Teilen der Fachliteratur oftmalsauch als Weiterentwicklung der bereits vorgestellten EAI angesehen. Definiert wird sie nach[Mel05] als eine „Systemarchitektur, die vielfältige, verschiedene und eventuell inkompa-tible Methoden oder Applikationen [hier: Anwendungsprogramme] als wiederverwendbareund offen zugreifbare Dienste repräsentiert und dadurch eine plattform- und sprachenu-nabhängige Nutzung und Wiederverwendung ermöglicht“. Ein wesentlicher Unterschiedzur EAI liegt in der Möglichkeit, eine lose Verknüpfung der Anwendungsprogramme und-systeme zu realisieren.Web Services stellen hierbei eine mögliche Implementierung einer SOA dar [Mel05], diedurch entfernte Aufrufe über die Webinfrastruktur in bestehende Systeme integriert wer-den. Die im Bereich der EAI über Adapter mit einem zentralen Bus verknüpften Anwen-dungsprogramme fungieren so in einer SOA beispielsweise als Web Services, womit auchder Begriff des Service-Paradigmas gemeint ist. Definitorisch betrachtet gibt es je nachVerwendungsbereich diverse Begriffserklärungen. Das W3C6 erklärt den Begriff wie folgt:

6http://www.w3.org/


Definition 3: Web ServiceA Web service is a software system designed to support interoperable machine-to-machineinteraction over a network. It has an interface described in a machine-processable format(specifically WSDL). Other systems interact with the Web service in a manner prescribedby its description using SOAP messages, typically conveyed using HTTP with an XMLserialization in conjunction with other Web-related standards.

Die Basiskomponenten einer SOA lassen sich durch die Begriffe der Kommunikation, derDienstbeschreibung und des Verzeichnisdienstes beschreiben. Hierfür gibt es Spezifikatio-nen, die die einzelnen Komponenten näher definieren. So spezifiziert das Netzwerkproto-koll SOAP das XML-basierte Nachrichtenformat der Kommunikation. Die Beschreibungdes Web Services erfolgt durch die Beschreibungssprache WSDL (Web Services Descrip-tion Language). Einen Überblick über angebotene Web Services ermöglicht das ProtokollUDDI (Universal Description, Discovery and Integration protocol), welches eine standar-disierte Verzeichnisstruktur spezifiziert und die Verwaltung von Web Service Metadatenorganisiert. Die Funktionsweise einer derartigen Architektur im Bereich der Unterneh-mensintegration lässt sich wie folgt beschreiben (siehe dazu die Abbildung 2.18).

Dienst-

verzeichnis

anbietendes

Unternehmen

anfragendes

Unternehmen

1. ve

röff

entl

ich

en

2. su

chen

3. V

erweis a

uf D

ienst

4. Abfrage der Dienst-

beschreibung

5. Nutzung

Abbildung 2.18: Service-orientierte Architektur in Anlehnung an [Mel05]

Im ersten Schritt veröffentlicht das Unternehmen, welches den Web Service anbietet, die-sen im entsprechenden Dienstverzeichnis (z. B. einen Web Service, der Auskunft über dieLieferdauer eines Vorproduktes geben kann). Ein anderes Unternehmen, welches zur Fer-tigungsplanung eines Produktes die Lieferdauer für ein Vorprodukt benötigt, sucht nunim Dienstverzeichnis nach einem geeigneten Web Service. Als Antwort auf die Suchan-frage erhält es einen Verweis auf den entsprechenden Dienst. Im Anschluss daran kanndas anfragende Unternehmen nun die Dienstbeschreibung vom anbietenden Unternehmenabfragen und den Web Service dann mit den entsprechenden Anfragen benutzen.Die in diesem Abschnitt vorgestellten Ansätze repräsentieren nur einen Bruchteil der Mög-lichkeiten, die im Rahmen der Unternehmensintegration zum Einsatz kommen können.Des Weiteren sei an dieser Stelle anzumerken, dass jeder Anwendungsfall einer Unter-nehmensintegration auf ganz individuelle Art und Weise umzusetzen ist und es keinePauschalrezepte zur Planung und Vorgehensweise bei der Verknüpfung von Unternehmen,Abteilungen, Prozessen, Anwendungsprogrammen und Funktionen gibt.

Kapitel 3

Klassifikation

In diesem Kapitel werden zwei unterschiedliche Klassifikationen von Produktkonfigura-toren vorgestellt. Im ersten und zweiten Abschnitt des Kapitels erfolgt die Darlegungverschiedener Kategorien einer sogenannten Globalklassifikation und die Erklärung derzugehörigen Klassen. Der dritte Abschnitt stellt eine Erweiterung für eine datensemanti-sche Klassifikation nach Liebisch vor, welche die im Produktkonfigurator zur Nutzungund Anwendung kommenden Informationen betrachtet.

3.1 Kategorien der Globalklassifikation

In der Fachliteratur ist mehrfach nachzulesen, dass sich durch die vielfältigen Anwendungs-bereiche für Produktkonfiguratoren eine Vielzahl an unterschiedlichen Systemen herausge-bildet hat, deren Klassifizierung die Abgrenzung und Bewertung weitestgehend erleichtert.Aus diesem Grund werden in diesem Abschnitt zunächst der Begriff der Globalklassifika-tion erläutert und im Anschluss daran die Kategorien derselbigen beschrieben. Es wird andieser Stelle die Bezeichnung der Globalklassifikation gewählt, da sich die Eigenschaftenüber verschiedene Themenbereiche erstrecken.Die Grundlage dieser Klassifikation stellt eine Einordnung des Objektes Produktkonfigu-rator anhand verschiedener Eigenschaften dar, die in Folge dessen in eine hierarchischeOrdnung überführt wurden. Die Eigenschaften selber verkörpern die Klassen der Klassifi-kation und werden in einer polyhierarchischen Klassifikationsstruktur den Kategorien, dieauch als Oberklassen bezeichnet werden können, zugeordnet. Die polyhierarchische Klas-sifikationsstruktur ist dadurch begründet, da eine Klasse auf Grund der unterschiedlichenSichtweisen mehreren Oberklassen zugeordnet werden kann.Die Herausbildung der vier Klassifikationskategorien erfolgte dabei in partieller Anleh-nung an das im Abschnitt 2.2.5 vorgestellte MVC-Architekturmuster. Demnach werdenim Fortlauf des Kapitels folgende Bezeichnungen verwendet:

• Basiskonzeptkategorie,• Datenmodellkategorie,• Präsentations- und Darstellungskategorie sowie• Logik- und Architekturkategorie.

39

40 KAPITEL 3. KLASSIFIKATION

Unter der Basiskonzeptkategorie werden alle Eigenschaften und Merkmale gebündelt, dieBezug nehmen auf die Grundkonzepte und elementaren Spezifikationen des Produktkon-figurators. Unterscheidungsmerkmale, deren Grundlage diejenigen Daten darstellen, dieim Produktkonfigurator ihre Verwendung finden, werden in der Datenmodellkategorie zu-sammengefasst. Die Präsentations- und Darstellungskategorie enthält alle Klassen, dieProduktkonfiguratoren in Hinblick auf die für den Benutzer relevanten äußeren Aspekteklassifizieren. Letztlich umfasst die Logik- und Architekturkategorie alle Merkmale, de-ren Grundlage die Systematik und die Konstruktion des Produktkonfigurators darstellen.Einen schematischen Überblick zu den Kategorien und Klassen der Globalklassifikationgibt das Klassifikationstentakel in Abbildung 3.1.

Global-

klassifikation

Basiskonzept-

kategorie

Produkt-

fertigung

Produktart

Einsatz-

gebiet

Anwenderart

Implemen-

tierung

Universalität

Gestaltungs-

spielraum

Logik- und

Architektur-

kategorie

Art der

Abhängig-

keitsprüfung

Architektur-

szenario

System-

interaktion

Datenmodell-

kategorie

Rekursions-

grad

Produkt-

wissens-

evolution

Integrations-

grad

Persistie-

rungsebene

Präsentations-

und Darstellungs-

kategorie

Startzustand

Konfigura-

tionsverlauf

Options-

darstellung Options-

kategori-

sierung

Entscheid-

ungsart

Defaults

Preis-

darstellung

Verkaufs-

unterstützung

Visuali-

sierung

Zeitpunkt der

Abhängig-

keitsprüfung

Abbildung 3.1: Klassifikationstentakel für Produktkonfiguratoren

3.2. KLASSEN DER GLOBALKLASSIFIKATION 41

3.2 Klassen der Globalklassifikation

Im Folgenden werden die zu den jeweiligen Kategorien gehörigen 24 Klassen erläutert. Essei an dieser Stelle nochmals darauf hingewiesen, dass die Zuordnung der Klassen aufgrunddes polyhierarchischen Charakters der Klassifikation nicht in jedem Fall der Eindeutigkeitunterliegt.

3.2.1 Klassen der Basiskonzeptkategorie

Die Klassen der Basiskonzeptkategorie entsprechen grundlegenden Merkmalen, die dasGrundkonzept und die Grundausrichtung eines Produktkonfigurators näher bestimmen.Es handelt sich dabei um die Klassen Gestaltungsspielraum, Universalität, Implemen-tierung, Anwenderart, Einsatzgebiet, Produktart und Produktfertigung, deren konkreteAusprägungen in der Abbildung 3.2 dargestellt sind und im Folgenden vorgestellt wer-den.

Basiskonzept-

kategorie

Produkt-

fertigung

Produktart

Einsatz-

gebiet

Anwenderart

Implemen-

tierung

Universalität

Gestaltungs-

spielraum

Modulkonfiguration

Mixkonfiguration

Anpassungskonfiguration

Business-to-Business

Business-to-Consumer

Spezialsystem

Universalsystem

Eigenentwicklung

Weiterentwicklung (Referenzsystem)

Standardsoftware

ModulbenutzungBack-End-System (Mitarbeiter)

Front-End-System (Kunde)

materielle Produkte

immaterielle Produkte

Variantenfertigung

kundenindividuelle Mehrfachfertigung

Abbildung 3.2: Klassifikationstentakel der Basiskonzeptkategorie

3.2.1.1 Gestaltungsspielraum

Die Klasse Gestaltungsspielraum differenziert die Produktkonfiguratoren in Bezug auf dieVielfalt der Möglichkeiten seitens des Kunden, das zugrunde liegende Produkt zu in-dividualisieren. Konkret unterteilt Scheer hierbei in die Ausprägungen Modul-, Mix-,Anpassungs- und Designkonfiguration. Bei der Modulkonfiguration werden dabei in ihrerAnzahl beschränkte Produktkomponenten (sogenannte Module) angeboten, die als solchein einer „standardisierten Grundform“ miteinander „kombinier- und parametrisierbar“sind [Sch06]. Als Beispiel sei an dieser Stelle ein sogenannter Plugin-Konfigurator zu nen-nen. Hierdurch hat ein Anwender die Möglichkeit, sich ein individuelles Softwarepaketzusammenzustellen, welches zum einen eine Basissoftware enthält, aber auch die durchden Konfigurationsvorgang ausgewählten Programmmodule, Plugins und Add-Ons. Eine


Veränderbarkeit der Module, Plugins oder Add-Ons ist hierbei jedoch nicht möglich. AlsVertreter für die Mixkonfiguration sind der im Abschnitt 2.2.6.2 vorgestellte Cerealienkon-figurator und diverse Blumenstrauß-Konfiguratoren zu nennen. Bei ihnen können eine Viel-zahl atomarer Produktkomponenten (vgl. Definition 2) miteinander kombiniert werden.Der Unterschied zwischen den beiden genannten Konfigurationsmöglichkeiten liegt in derAtomarität und den Abhängigkeiten der Produktkomponenten. Die als Module bezeichne-ten Produktkomponenten können z. B. in weitere Komponenten zerlegt werden; sie besitzendemnach nicht die Eigenschaft der Atomarität. Zudem existieren in der Modulkonfigurati-on mehr Abhängigkeiten zwischen den Produktkomponenten als bei der Mixkonfiguration.Die dritte Gruppe der Produktkonfiguratoren verfolgt das Konzept der Anpassungskonfi-guration. Hierbei wird ein „in der Grundform definiertes Produkt“ angeboten, welches anbestimmten festgelegten Ansatzpunkten veränderbar ist. Scheer nennt hier als Beispieleinen Jeans-Konfigurator. Ein weiterer Vertreter dieser Ausprägung kann aber auch in ei-nem Stift-Konfigurator gesehen werden. Der Stift (z. B. ein Füllfederhalter) entspricht demvordefinierten Produkt. Die festgelegten Ansatzpunkte können hierbei z. B. der Schriftfar-be, der Außenfarbe, der Größe und der Schafthalterungsform des Stiftes entsprechen. Sollnun noch die grundlegende Form des Stiftes oder das Muster der Stifthülle individuellumgestaltet werden, so bezeichnet man diese Art als Designkonfiguration.

Sie wird im Rahmen dieser Arbeit allerdings nicht als Ausprägung zur Klasse Gestaltungs-spielraum gezählt, da eine Abgrenzung zwischen einem Produktkonfigurator einerseits undeinem Designwerkzeug andererseits definiert wurde (siehe dazu Abschnitt 2.2.1). Die Artder Designkonfiguration ist demnach dem Klassifikationsobjekt „Designwerkzeug“ zuzu-ordnen. Auch in Bezug auf die drei anderen Ausprägungen muss an dieser Stelle daraufhingewiesen werden, dass es eine Frage der Sichtweise ist, wie ein Modul definiert ist undwelche Möglichkeiten der Veränderbarkeit dadurch gegeben sind, sodass sich letztlich dieEinordnung eines Produktkonfigurators in eine der drei Dimensionen anhand der gegebe-nen Granularität entscheidet.

3.2.1.2 Universalität

Produktkonfiguratoren können in Hinblick auf deren universelle Einsetzbarkeit nach Gö-bel in Spezial- und Universalsysteme unterschieden werden [Göb09]. Scheer bezeichnetdie beiden Ausprägungen auch als Ein- und Mehrproduktkonfiguratoren. Erstgenanntezeichnen sich dadurch aus, dass sich ihre Funktionalität nur auf ein spezifisches, im Vor-feld definiertes Produkt anwenden lässt. Ein solcher Produktkonfigurator ist somit speziellauf die Zusammensetzung eines bestimmten Produktes und dessen Unterstützung im Ver-kaufsprozess ausgerichtet [Lec06]. Daraus ergibt sich auch eine Beschränkung auf ein dasProdukt anbietende Unternehmen. Ein Beispiel für ein solches Spezialsystem ist der „CarConfigurator“ der Porsche AG1, welcher durch die Jenaer Firma ORISA2 entwickelt wur-de. Scheer fasst hinsichtlich der Definition für Einproduktkonfiguratoren nach Lecknereinen nicht ganz so engen Rahmen, indem er sagt, dass derartige Produktkonfiguratorenauch die Konfiguration „mehrerer Produkte in einem Unternehmen oder einer Domäne“ermöglichen.

1http://www.porsche.com/2http://www.orisa.de/


Im Gegensatz dazu lassen sich mit Universalsystemen bzw.Mehrproduktkonfiguratoren ver-schiedene Produkte in unterschiedlichen Unternehmen konfigurieren. Ein Vertreter hierfürist CREALIS® (siehe Abschnitt 2.2.6.1).

3.2.1.3 Implementierung

Aus Sicht des Unternehmens, welches sich für den Einsatz eines Produktkonfiguratos ent-schieden hat, sind die Kostenfaktoren zur Implementierung (womit an dieser Stelle auchdie Entwicklung eingeschlossen wird) von erheblicher Bedeutung. In einem engen Zusam-menhang dazu steht die Art der Implementierung, welche innerhalb der gleichnamigenKlasse detaillierter betrachtet wird. In [Sch06] findet man hierzu eine Unterscheidungu. a. in die Eigenentwicklung, Weiterentwicklung ausgehend von einem Referenzsystem,Standardsoftware oder Modulbenutzung. Die Eigenentwicklung bietet größtmögliche Fle-xibilität, da hierbei alle Anforderungen, Wünsche und Begehrlichkeiten des Unternehmensbeachtet werden können; sie zieht in der Regel aber auch die höheren Kosten für die Im-plementierung nach sich. Bei der Weiterentwicklung ausgehend von einem Referenzsystemwird von bereits vorhandenem Programmcode profitiert und es besteht die Möglichkeit,existierende Systeme in deren Funktionalität zu spezialisieren. Die Grundvoraussetzunghierfür ist allerdings, dass das Referenzsystem quelloffen verfügbar ist. Der Kostenfaktorist dennoch erheblich, da sich die Entwickler erst in die bestehenden Systeme einarbeitenmüssen. Diese Art der Implementierung findet in der Gegenwart immer häufiger Anwen-dung durch die zunehmende Verbreitung der „Open Source“-Philosophie3.

Der Einsatz von Standardsoftware ist gerade dann für Unternehmen geeignet, wenn eineeinfache Modularisierung der Produkte gegeben ist bzw. sich die Produkte wie in der Soft-ware vorgesehen modularisieren lassen. Zudem ist diese Variante von Vorteil, wenn die Un-ternehmen nicht auf eine intern vorhandene Entwicklungsabteilung zurückgreifen können.Wird durch das Unternehmen bereits eine Shop-Software eingesetzt, über die die Kundenbereits Produkte bestellen können, so besteht die Möglichkeit, derartige Shop-Systememit Modulen zu erweitern. So gibt es beispielsweise für das Shop-System xt:Commercezwei Module4, die die Grundfunktionalität eines Produktkonfigurators realisieren. Einederartige Modulbenutzung eignet sich allerdings nur in sehr begrenztem Maße und ist imSinne des Funktionsumfangs und der Mächtigkeit nicht zu vergleichen mit den anderengenannten Arten.

3.2.1.4 Anwenderart

Produktkonfiguratoren haben nicht nur einen verkaufsfördernden Charakter (siehe dazuauch Abschnitt 2.2). Aus diesem Grund lassen sich Produktkonfiguratoren unterscheidennach deren überwiegende Anwendergruppen. In [Lec06] finden sich hierzu die Ausprä-gungen Mitarbeiter und Kunden. Scheer bezeichnet die Ausprägungen entsprechend alsBack-End-Systeme und Front-End-Systeme. In der Regel werden Back-End-System vorallem für die Mitarbeiter konzipiert. Front-End-Systeme dagegen dienen in der Regel zurInteraktion des Kunden mit dem Produktkonfigurator.

3http://www.opensource.org/4http://www.bui-hinsche.de/


3.2.1.5 Einsatzgebiet, Produktart und Produktfertigung

Drei weitere Klassen betrachten das Einsatzgebiet, die Art und die Fertigung des Pro-duktes. Erstere ist dabei untergliedert in die im Abschnitt 2.2.2 vorgestellten Einsatzge-biete, welche vordergründig auf die Bereiche B2C sowie B2B abzielen. Auch die in einemProduktkonfigurator als Grundlage dienenden Produktarten, konkret die Unterscheidungin materielle und immaterielle Produkte, wurden bereits in den Abschnitten 2.1.3.1 und2.1.3.2 näher betrachtet. Gleiches gilt für die beiden Fertigungstypen, die für die Produkt-konfiguration als geeignet eingestuft wurden (siehe dazu Abschnitt 2.1.4.2). Daher wirdan dieser Stelle auf eine nähere Betrachtung der Ausprägungen verzichtet.

3.2.2 Klassen der Datenmodellkategorie

Produkte werden durch Informationen beschrieben und durch diese in einem Produktkon-figurator abgebildet. Die Datenmodellkategorie (siehe dazu auchAbbildung 3.3) umfasstvier Klassen, die als Rekursionsgrad, Produktwissensevolution, Integrationsgrad und Per-sistierungsebene bezeichnet und nun näher betrachtet werden.

Datenmodell-

kategorie

Rekursions-

grad

Produkt-

wissens-

evolution

Integrations-

grad

Persistie-

rungsebene

Tiefe 1

Tiefe 2

. . .

Tiefe n

keine Erfassung

Erfassung von Änderungen

Erfassung mit Versionierung

nicht integrativ

(beidseitig) datenintegrativ

(beiseitig) daten- und anwendungsintegrativ

Datenbank

Dateisystem

Abbildung 3.3: Klassifikationstentakel der Datenmodellkategorie

3.2.2.1 Rekursionsgrad

Unter der Klasse Rekursionsgrad ist die Tiefe zu verstehen, wie weit eine Produktkom-ponente entsprechend der Definition 1 des Produktbegriffes (siehe dazu Abschnitt 2.1.1)konfiguriert werden kann. Sie wird in dieser Arbeit zur Datenmodellkategorie gezählt,da abhängig von der Rekursionstiefe entsprechende Informationen im System benötigtwerden. Folglich existiert bei einem Produkt, welches bis in die Einzelheiten einer je-den Komponente konfigurierbar ist, ein umfangreicheres und komplexeres Datenmodellals bei einem Produkt, welches nur in der reinen Zusammensetzung seiner Komponenten


konfigurierbar ist. Die Ausprägungen dieser Klasse entsprechen der numerischen Rekursi-onstiefe, also dem eigentlichen Rekursionsgrad. Ein Beispiel hierfür ist die Konfigurationeines Autos. Die Zusammenstellung der Grundkomponenten (z. B. Sitze) entspricht demRekursionsgrad 1, die Auswahl des Sitzbezuges (z. B. Stoff oder Leder) oder der Art desSitzes (z. B. Sportsitzschale) entspricht dagegen dem Rekursionsgrad 2, da es sich hier-bei um Produktkomponenten handelt, die sich direkt auf die Produktkomponente „Sitz“beziehen. Dieses lässt sich nun beliebig fortführen.

3.2.2.2 Produktwissensevolution

Die Evolution des Produktwissens beschreibt die fortwährende Veränderung aller Daten,die über sämtliche konfigurierbare Produkte vorliegen. Die Änderung dieser Daten hateinen zwangsläufigen Charakter, da sich im Laufe der Zeit Anpassungen aufgrund von di-versen Erkenntnissen aus der Auswertung des Produktlebenszyklus (siehe dazu Abschnitt2.1.5) ergeben oder aber unternehmenseigene Aktivitäten Änderungen an den Produkt-daten hervorrufen. Auch besteht die Möglichkeit, dass einem Produkt neue Komponentenzugeordnet werden. Diesbezüglich gibt es unterschiedliche Ausprägungen von Produktkon-figuratoren. Hierbei werden nur die Möglichkeiten des Produktkonfigurators als Softwarebetrachtet und nicht die Möglichkeiten der Speicherungsssysteme, die für die Verwaltungder Daten auf der Ebene des Betriebssystems sorgen. Die trivialste Variante unterstütztkeine Erfassung von Änderungen. Die Datenmodelle müssen neu erstellt und in das Sys-tem eingearbeitet werden, sobald es zu Änderungen kommt. Die in der Gegenwart alsStandard etablierte Variante hingegen unterstützt die Erfassung von Änderungen durchdas Bereitstellen von Schnittstellen zur Datenmanipulation oder eines entsprechenden Ver-waltungsbereiches, über den die Daten verändert werden können. Die dritte Ausprägungbietet zudem die Möglichkeit der Versionierung an. Darunter ist zu verstehen, dass jederVorgang, der zu einer Änderung der Daten im Produktkonfigurator führt, protokolliertwird und darüber hinaus Sicherungen über die dann alten Informationen erstellt werden.Dadurch ist z. B. gewährleistet, dass zwischen den einzelnen Evolutionsstufen gewechseltwerden kann.

3.2.2.3 Integrationsgrad

Die Mehrheit der Informationen, die in einem Produktkonfigurator berührt werden, sindbereits an anderen Stellen des einsetzenden Unternehmens in der Bearbeitung oder Ver-wendung gewesen oder werden dort benötigt. Der Sinn und Zweck einer Integration vonderartigen Daten, aber auch von Programmen und Funktionen, wurde bereits im Abschnitt2.3 verdeutlicht. Diesbezüglich lassen sich Produktkonfiguratoren in fünf wesentliche Ty-pen unterscheiden: Ersterer entspricht dabei einem nicht integrativen Produktkonfigurator.Dieser ist dadurch gekennzeichnet, dass jegliches Produktwissen erst in das System eingear-beitet werden muss, bevor es darin als verfügbar gilt. Zudem werden hier alle notwendigenFunktionen direkt implementiert, d. h. es muss bzw. kann auf keine externen Funktionenoder Programme zugegriffen werden, um die gewünschte Funktionalität zu gewährleisten.Derartige Systeme werden auch als „Standalone-Systeme“5 bezeichnet. Der zweite Typentspricht genau denjenigen Produktkonfiguratoren, die Informationen aus existierendenVerwaltungs- und Informationssystemen integrieren. Somit kann eine unerwünschte re-

5Der Begriff findet oftmals auch Anwendung im Bereich der Architektur von Client/Server-Systemen.


dundante Datenhaltung verhindert werden. Dieser Umstand ist jedoch in Situationen, indenen die Integrationsschnittstelle oder das dahinterliegende System nicht funktionsfähigbzw. nicht erreichbar ist, von erheblichem Nachteil, da nicht auf die Daten zurückgegriffenwerden kann. Solche Systeme werden an dieser Stelle als datenintegrative Produktkonfigu-ratoren bezeichnet. Eine Erweiterung dazu stellt der dritte Typ dar. Bei diesem kann eineIntegration von Daten in zweierlei Richtung erfolgen. Neben der Datenintegration in denProduktkonfigurator ist dieser auch in der Lage, Daten in die angekoppelten Systeme zuverteilen, sodass eine beidseitige Datenintegration vorliegt. Der vierte Typ entspricht einemProduktkonfigurator, der zusätzlich zu den Informationen auch externe Programme undFunktionen integrieren kann. Ein Beispiel für ein derartiges System ist die Benutzung einesexternen Programms zur Auswertung des Nutzerverhaltens während einer Produktkonfi-guration. Dieser Typ wird in dieser Arbeit auch als daten- und anwendungsintegrativerProduktkonfigurator bezeichnet. Analog zur Datenintegration stellt der fünfte Typ auchhier eine Erweiterung des vierten Typs dar. Dieser ist in der Lage, interne Programmeund Funktionen angekoppelten Systemen zur Verfügung zu stellen, z. B. die Technik zurAbhängigkeitsprüfung.

3.2.2.4 Persistierungsebene

Die Klasse Persistierungsebene beschreibt die Art und Weise, wo und wie die Daten ge-speichert werden. Hierzu unterscheidet Liebisch die Ausprägungen Datenbank und Datei-system. Der Vergleich beider Ausprägungen basiert dabei auf einem Teil der in [Küs10]genannten Datenhaltungsanforderungen. Die folgende Tabelle 3.1 bietet hierzu einenkurzen Überblick.

Merkmal Datenbank DateisystemDatenmenge + oDatensicherung + −

Datenunabhängigkeit + −

Integrationsfähigkeit + −

Installation und Wartung − +

Parallelzugriff (schreibend) + −

Zugriffsschutz (werteabhängig) + −

Legende:+: geeignet | o: neutral | −: ungeeignet

Tabelle 3.1: Vergleich von Datenbank und Dateisystem als Persistierungsebene

Datenbanken bzw. Datenbankmanagementsysteme (DBMS) eignen sich für die struktu-rierte Verwaltung insbesondere von großen Datenmengen. Die Grundkonzepte von DBMSsorgen für die Gewährleistung der als „ACID“ bezeichneten Eigenschaften. Das AkronymACID steht dabei für die Begriffe der Atomarität (atomicity), Konsistenz (consistency),Isoliertheit (isolation) und Dauerhaftigkeit (durability) [HR83]. Die Gegebenheit dieserEigenschaften ist einer der Gründe, warum DBMS für die Verwendung als Persistierungs-ebene bei Produktkonfiguratoren geeignet sind. Während bei einem DBMS ein konzipiertesund nahezu unabhängiges System die Verwaltung der Informationen übernimmt, erfolgtbei der zweiten Ausprägung, dem Dateisystem, die Verwaltung durch das Betriebssystem.


Bereits beim ersten Merkmal der Datenmengen gibt es Unterschiede zwischen beiden Aus-prägungen. Da es in allen Dateisystemen Vorgaben für die maximal zulässige Größe einerDatei gibt, müssen im schlechtesten Fall Dateneinheiten auf mehrere Dateien verteilt ab-gelegt werden. Die Verwaltung und Zuordnung der zusammengehörenden Dateien mussdann durch den Produktkonfigurator oder durch ein externes Programm erfolgen, da dasDateisystem als solches hierbei keine Unterstützung anbietet. Im Vergleich dazu bedarfes bei der Verwendung eines DBMS keinerlei Implementierungen, da das DBMS selbstdie Organisation der Daten vornimmt. Ähnliches trifft auch auf die Datensicherung zu.Während bei einem DBMS derartige Sicherungsmechanismen integraler Bestandteil sind,bedarf es bei der Verwendung des reinen Dateisystems zusätzlicher Anwendungen, welchedie derartige Funktionalität realisieren.Durch die bereits erwähnte strukturierte Verwaltung der Daten bei einem DBMS genießtdieses weiterhin Vorteile bei der Datenunabhängigkeit. Sobald es beispielsweise zu struk-turellen Änderungen innerhalb einer Datei kommt, muss der Produktkonfigurator als An-wendungsprogramm angepasst werden, damit auch weiterhin auf die Informationen ausdem Dateisystem richtig zugegriffen werden kann. Es liegt demnach keinerlei Flexibilitätvor, wenn das Dateisystem als Persistierungsebene genutzt wird, da eine Abhängigkeit zurgewählten Dateiorganisationsform besteht. Auch die Sortierreihenfolge der Einträge in ei-ner Datei ist ein Beispiel für eine derartige Abhängigkeit. Der Zugriff auf die Daten erfolgtbei der Verwendung eines DBMS über eine Abfragesprache. Hierdurch ist eine, wenn aucheingeschränkte, Flexibilität in Bezug auf Strukturveränderungen gegeben.Damit im Zusammenhang steht auch das Merkmal der Integrationsfähigkeit. Für externeProgramme ist es wesentlich einfacher, mittels genormter Abfragesprachen auf Datenbe-stände zuzugreifen als für jede Dateiorganisationsform einen speziellen Parser zu konstru-ieren, der dann fallbasiert eingesetzt wird. Auch der entstehende Overhead bei der Abfragevon Informationen kann durch die Verwendung von Abfragesprachen immanent reduziertwerden, da nur genau diejenigen Daten abgefragt werden, die notwendig sind; hingegenmüssen bei einem Dateisystem die Dateien als solche erst geöffnet und die notwendigenDaten anschließend heraus gefiltert werden.Das Dateisystem erweist sich gegenüber dem DBMS im Bereich der Installation und War-tung als vorteilhaft, da es als solches bereits gegeben ist, das DBMS dagegen erst installiertund später regelmäßig gewartet werden muss. Durch die Wartung des DBMS fallen zudemFolgekosten an, falls der Anbieter des Produktkonfigurators diese nicht selber vornimmt.Wiederum umgekehrt verhält es sich beim Parallelzugriff auf Daten. Wenn verschiedeneMitarbeiter Änderungen am selben Datenbestand des Produktkonfigurators vornehmen,kann es durchaus vorkommen, dass zur selben Zeit Änderungen an der selben Dateneinheitvorgenommen werden. Dieser als Parallelzugriff bezeichnete Umstand kann bei der Ver-wendung eines DBMS auf einer sehr fein granularen Ebene durchgeführt werden. Zudemgewährleistet das DBMS durch die ACID-Eigenschaften, dass einmal durchgeführte Ände-rungen auch dauerhaft erhalten bleiben. Dies ist bei einem Dateisystem nicht immer derFall. Wird z. B. für die Änderung eines Produktpreises die entsprechende Datei geöffnetund manipuliert, kann unter Umständen gleichzeitig ein weiterer Mitarbeiter die selbe Da-tei bereits geöffnet haben, um eine andere Information zu verändern. Nimmt dieser späterdie Speicherung seiner Dateiänderung vor, wird die Preisänderung wieder überschrieben.Es sei hierbei jedoch darauf hingewiesen, dass es auch in Dateisystemen Mechanismengibt, die bei einem gleichzeitigen Öffnen einer identischen Datei Hinweise an die Benutzerübermitteln und Schreibsperren einsetzen.


Auch für den Zugriffsschutz ist die bereits erwähnte fein granulare Eigenschaft relevant.Bei einem DBMS besteht die Möglichkeit, die Zugriffsrechte werteabhängig zu definieren.Dies ist bei einem Dateisystem nicht möglich, da diesem die Kenntnisse zur Datensemantikfehlen. Die Rechtevergabe erfolgt hierbei für eine Datei insgesamt, nicht aber für bestimmteWerte, die innerhalb der Datei gespeichert werden.

Neben diesen Merkmalen gibt es eine Reihe weiterer Unterscheidungsmerkmale, die aberan dieser Stelle nicht aufgegriffen werden. Stattdessen sei dafür auf [HSS07] und [Kem09]verwiesen.

3.2.3 Klassen der Präsentations- und Darstellungskategorie

Die für den Nutzer am deutlichsten wahrnehmbaren Merkmale eines Produktkonfigura-tors sind in der Regel diejenigen Merkmale, die in irgendeiner Art und Weise für ihnvisuell sichtbar und erlebbar sind. Derartige Eigenschaften spiegeln sich in den Klassender Präsentations- und Darstellungskategorie wider und stimmen mit einem Teil der inAbschnitt 2.2.4.1 genannten Anforderungen aus der Kunden- bzw. Anbietersicht überein.Einen Überblick über die Ausprägungen der verschiedenen Klassen vermittelt die folgendeAbbildung 3.4.

Präsentations-

und Darstellungs-

kategorie

Startzustand

Konfigura-

tionsverlauf

Options-

darstellung Options-

kategori-

sierung

Entscheid-

ungsart

Defaults

Preis-

darstellung

Verkaufs-

unterstützung

Visuali-

sierung

Neukonfiguration

Basiskonfiguration

geladene Konfiguration

Batchkonfiguration

interaktive Konfiguration

angepasste Darstellung

vollständige Darstellung

fehlende Kategorisierung

inhaltliche Kategorisierung

Top-Down-Ansatz

Bottom-Up-Ansatz

Voreinstellungen

Empfehlungen

Aufpreis

Gesamtpreis

ersetzendes Verkaufssystem

ergänzendes Verkaufssystemtextbasiert

vordefiniertes Medium

zur Laufzeit generiertes Medium

Abbildung 3.4: Klassifikationstentakel der Präsentations- und Darstellungskategorie

3.2.3.1 Startzustand der Konfiguration

Startet ein Kunde den eigentlichen Konfigurationsprozess des Produktkonfigurators, sotrifft er dabei auf unterschiedliche Voreinstellungen hinsichtlich der Auswahl von Produkt-komponenten. Nach Scheer gibt es zwei unterschiedliche Ausprägungen hinsichtlich desStartzustandes der Konfiguration [Sch06]. Im Detail unterscheidet er zwischen einer Neu-konfiguration einerseits und einer Basiskonfiguration andererseits. In dieser Arbeit wird


zudem eine weitere Ausprägungsart betrachtet, die als geladene Konfiguration bezeichnetwird.

Bei einer Neukonfiguration startet der Konfigurationsprozess sozusagen mit einem lee-ren Anfangszustand, d. h. es werden keinerlei Produktkomponenten vorausgewählt. DerKunde hat so von Anfang an freie Auswahl. Als Beispiel hierfür sei an dieser Stelle derCerealienkonfigurator genannt. Im Unterschied dazu startet der Konfigurationsprozess beider Basiskonfiguration mit vorausgewählten Produktkomponenten, die bereits eine gülti-ge Konfiguration darstellen. Der Kunde hat hierbei die Möglichkeit, die bestehende Ba-siskonfiguration in einer limitierten Anzahl von Eigenschaften zu verändern oder sie mitgültigen Produktkomponenten zu erweitern bzw. zu ersetzen. Exemplarisch für diese Aus-prägung sei der PC-Konfigurator der Firma DELL6 genannt. Bei diesem kann in einemersten Schritt ein Computer ausgewählt werden, welcher hierbei der Basiskonfigurationentspricht. Im darauf folgenden Konfigurationsprozess können dann der Computer in sei-nen definierten Eigenschaften verändert und zusätzliche Peripherieelemente und -geräteausgewählt werden. Ähnlich der Basiskonfiguration ist die dritte Ausprägung der gelade-nen Konfiguration. Auch hier startet die Konfiguration mit einer spezifischen Zusammen-stellung. Der Unterschied zur Basiskonfiguration liegt in der Zuordnung der Konfigurationzu einem Kunden, der diese bereits zu einem früheren Zeitpunkt zusammengestellt hat.

3.2.3.2 Konfigurationsverlauf

Die Klasse Konfigurationsverlauf beschäftigt sich mit der Abfolge der einzelnen Schrittedes Konfigurationsprozesses, an dessen Ende entweder das zu konfigurierende Produkt oderein anderweitiges Ergebnis steht. Scheer unterscheidet in seinem morphologischen Rah-men von Produktkonfiguratoren hierbei die Ausprägungen Batchkonfiguration, interaktiveKonfiguration und Rekonfiguration. Letztere wird in dieser Arbeit allerdings nicht als Aus-prägung der Klasse „Konfigurationsverlauf“ betrachtet, sondern unter der Bezeichnung dergeladenen Konfiguration der Klasse „Startzustand der Konfiguration“ zugeordnet.

Bei der Batchkonfiguration, die auch als Zielgrößenkonfiguration bezeichnet werden kann,werden im ersten Schritt die Vorstellungen des Kunden erfragt und aus diesen dann einvollständiges Konfigurationsergebnis anhand der gegebenen Möglichkeiten abgeleitet. Da-gegen erfolgt bei der interaktiven Konfiguration ein unmittelbares Eingreifen des Kundenin den Konfigurationsprozess. Während er bei der Batchkonfiguration lediglich als Inter-viewpartner fungiert, nimmt er nun direkt die Aus- und Abwahl der Produktkomponentenvor. Diese Art der Konfiguration kann auch als Optionenkonfiguration bezeichnet werden.Im Rahmen dieser Arbeit wird die interaktive Konfiguration weitergehend in die iterativeund die wahlweise Konfiguration differenziert. Bei der iterativen Konfiguration erfolgt dieZusammenstellung eines Produktes durch das schrittweise Aus- und Abwählen der Pro-duktkomponenten. Die Reihenfolge, welche Produktkomponente zu welchem Zeitpunkt zurAus- oder Abwahl bereit steht, wird dabei durch den Produktkonfigurator vorgegeben. AlsBeispiel sei an dieser Stelle der Catering-Konfigurator genannt, der im Abschnitt 2.2.6.3vorgestellt wurde. In [BAKF04] wird diese Ausprägung auch als sogenannte „Assistenten-Metapher“ bezeichnet. Bei der wahlweisen Konfiguration ist es dagegen der Kunde, derdie Reihenfolge der zu konfigurierenden Produktkomponenten bestimmt. Diese Art wird

6http://www.dell.de/


ebenda als sogenannte „Werkzeug-Metapher“ bezeichnet. Ein Vertreter hierfür ist der PC-Konfigurator der Firma Alternate7.

3.2.3.3 Optionsdarstellung

Die Klasse Optionsdarstellung differenziert Produktkonfiguratoren dahingehend, wie vieleProduktkomponenten in den einzelnen Konfigurationsschritten angezeigt werden. Genauerbetrachtet erfolgt eine Unterscheidung in eine angepasste und eine vollständige Darstel-lung. Erstere ist dadurch gekennzeichnet, dass während des Konfigurationsprozesses immernur die gültigen Produktkomponenten angezeigt werden, d. h. diejenigen, die durch die be-reits getroffenen Entscheidungen überhaupt noch wählbar sind. Dieses Vorgehen hat denVorteil einer hohen Übersichtlichkeit für den Kunden, da auf ungültige Produktkomponen-ten verzichtet wird. Zudem erfolgt hierdurch die erhebliche Reduzierung einer möglichenKonfliktgefahr.

Nachteilig wirkt sich dies aber auf die Transparenz aus, denn dem Kunden werden potenti-elle Möglichkeiten (in alternativen Konfigurationsverläufen) vorenthalten. Gegenteiliges istbei der vollständigen Darstellung zu benennen: Der Kunde hat unabhängig von den getrof-fenen Entscheidungen eine Auflistung aller Produktkomponenten vorliegen. Hier ist einePrüfung der getroffenen Entscheidung notwendig, da auch ungültige Produktkomponentendurch den Kunden wählbar sind. Stellt der Produktkonfigurator eine ungültige Wahl fest,erfolgt ein unterstützender Hinweis an den Kunden. Den Unterschied zwischen den beidenAusprägungen soll das folgendes Beispiel veranschaulichen: Ein Kunde konfiguriert z. B. einAuto und hat bereits in einem Konfigurationsschritt einen Sitz aus Leder ausgewählt, derkeine Sitzheizung erlaubt. Bei der angepassten Darstellung wird dem Kunde so in einemFolgeschritt die Produktkomponente „Sitzheizung“ nicht mehr angezeigt, hingegen erfolgtbei der vollständigen Darstellung auch die Anzeige dieser Produktkomponente. Letztlichwird dem Kunden genau durch diese Art der Optionsdarstellung deutlich gemacht, welcheEntscheidungsmöglichkeiten er hinsichtlich der verschiedenen Produktkomponenten hat.

3.2.3.4 Optionskategorisierung

Die für eine Produktzusammenstellung zur Auswahl stehenden Produktkomponenten kön-nen in verschiedener Anordnung dargestellt werden. Eine Studie von Polak unterscheidetdabei eine fehlende und eine inhaltliche Kategorisierung der Produktkomponenten [Pol08].Die Studie betrachtet dabei für die Untersuchung neben der Art der Kategorisierung auchdas Produktwissen der Kunden. Im Ergebnis trifft sie Aussagen über das in direkter Ab-hängigkeit zu den genannten Untersuchungsgegenständen stehende Entscheidungsverhal-ten der Kunden bei der Auswahl von Produktkomponenten.

In Bezug auf einen Kunden mit wenig eigenem Produktwissen kommt Polak zu derErkenntnis, dass eine inhaltliche Kategorisierung hierbei einen Einfluss auf das Entschei-dungsverhalten des Kunden ausübt. Die Ursache liegt ihm zufolge hierbei in der Funktionder Orientierungshilfe, die eine Kategorisierung auf den Kunden bezogen darstellt. Beieinem Kunden mit mittleren bis hohen eigenem Produktwissen führt der Studie zufolgeeine inhaltliche Kategorisierung nicht zwingend zur Beeinflussung des Entscheidungsver-

7http://www.alternate.de/


haltens. Dies liegt an der gefühlten Sicherheit, die der Kunde aufgrund seines Wissensverspürt, sodass er auf eine derartige Orientierungshilfe nicht angewiesen ist.

Aus diesen Gründen kommt die Studie mit Blick auf den Anbieter zu dem Ergebnis, dassdieser nur dann auf eine inhaltliche Kategorisierung der Produktkomponenten verzich-ten sollte, wenn für die Kunden ein mittleres bis hohes Produktwissen (d. h. die Kundenentsprechen dann sogenannten Experten) vorausgesetzt werden kann.

3.2.3.5 Entscheidungsart

Bisher wurden bereits die Bezeichnungen der Aus- und Abwahl von Produktkomponentenverwendet. Diese entsprechen den beiden Ausprägungen der in diesem Absatz betrachtetenKlasse Entscheidungsart. Polak verwendet für sie die Begriffe des Bottom-Up-Ansatzeseinerseits und des Top-Down-Ansatzes andererseits.

Für die Erklärung der beiden Arten wird das folgende Beispiel zur Veranschaulichungherangezogen: ein Produktkonfigurator ermögliche das Zusammenstellen eines Fahrrads.Hierbei gibt es 20 verschiedene Produktkomponenten, die unter Beachtung der jeweili-gen Abhängigkeiten zusammengestellt werden können. Bei dem Bottom-Up-Ansatz erfolgtdurch den Kunden nun die Auswahl der gewünschten Produktkomponenten, d. h. er se-lektiert zuerst den Rahmen des Rades, dann die Pedalen, gefolgt von einem Sattel bis hinzu einer bequemen Lenkerstange. Diejenigen Produktbestandteile, auf die er bei seinemRad verzichten will, wie z. B. Schutzbleche, werden nicht ausgewählt. Im Vergleich dazustartet die Konfiguration bei dem als Top-Down bezeichneten Ansatz mit einem Rad, beidem alle 20 nicht in Konflikt zueinander stehenden Produktkomponenten bereits selek-tiert sind. Der Kunde deselektiert nun genau diejenigen Produktbestandteile, die er nichtan seinem Rad wiederfinden möchte, wie z. B. die erwähnten Schutzbleche. Alle anderenProduktkomponenten bleiben ausgewählt.

Polak verweist in seiner Studie auf Forschungsergebnisse, die besagen, dass Kunden mehrProduktkomponenten in eine Zusammenstellung einfließen lassen, wenn der Produktkon-figurator den Top-Down-Ansatz verfolgt. Allerdings ist auch bekannt, dass gerade dieserAnsatz für den Kunden zu einer erhöhten Entscheidungsschwierigkeit führt, weil er sichnicht entscheiden kann, welche der bereits selektierten Produktkomponenten abgewähltwerden sollen.

3.2.3.6 Defaults

Eine Variante, die im Abschnitt 3.2.3.5 angesprochene Entscheidungsschwierigkeit zu re-duzieren, findet sich in den sogenannten Defaults, die in der gleichnamigen Klasse denBetrachtungsgegenstand darstellen. Defaults sind Empfehlungen, die der Produktkonfigu-rator dem Kunden ausspricht. Polak differenziert in harte und weiche Defaults. Ersteresind Voreinstellungen, die bedingungslos durch den Produktkonfigurator an den Kundenweitergegeben werden. Zweitere sind Empfehlungen, die der Produktkonfigurator in Ab-hängigkeit des aktuellen Konfigurationszustandes dem Kunden gegenüber anzeigt. Derar-tige Defaults lassen sich nach [Lec06] zudem in nicht-personalisierte und personalisierteEmpfehlungen differenzieren. Der Unterschied liegt dabei in der Auswertung der Konfigu-rationsentscheidungen des Kunden.


Während bei den nicht-personalisierten Empfehlungen einzig die kundenunabhängige Aus-wahl der Produktkomponenten eine Rolle spielt, werden bei der personalisierten Vorge-hensweise Entscheidungen des bestimmten Kunden berücksichtigt. Dabei gibt es unter-schiedliche Herangehensweisen bei der Implementierung einer Komponente zur Generie-rung von personalisierten Empfehlungen. Beispielsweise können die dafür notwendigen Da-ten über Cookies, die Session-ID oder aber über ein erzwungenes Anmelden des Kundenim System erfasst werden. Zur Verdeutlichung sei das folgende Beispiel genannt: Hat derKunde eine Vorliebe für preiswerte Produktkomponenten, werden ihm diese auch emp-fohlen, um so den kundenbezogenen Umsatz zu steigern. Ein Vertreter hierfür ist daspersonalisierte Empfehlungssystem der Firma Amazon8.Laut einer Studie aus [Pol08] haben Defaults eine positive Wirkung auf die Zufriedenheitder Kunden bezogen auf das Konfigurationsergebnis. Zudem führen sie in Verbindungmit dem Top-Down-Ansatz zu einer geringeren Anzahl an Deselektionen, d. h. es werdenweniger Produktkomponenten und Eigenschaften abgewählt. Ein Grund hierfür liegt inder bereits erwähnten Reduzierung der Entscheidungsschwierigkeit.

3.2.3.7 Preisdarstellung

Hinsichtlich der Klasse Preisdarstellung lassen sich zwei Ausprägungen unterscheiden:Aufpreis- und Gesamtpreisdarstellung. Bei Ersterer werden in jedem Konfigurationsschrittdie Produktkomponenten mit ihrem jeweiligen Preis angezeigt. Für den Kunden bedeutetdies eine größtmögliche direkte Transparenz, da er bei jeder Produktkomponente im Kla-ren darüber ist, wie stark sich diese auf die Gesamtpreisberechnung auswirkt. Diese direkteTransparenz fehlt bei der Gesamtpreisdarstellung. Zwar merkt der Kunde, dass sich derGesamtpreis verändert und kann daraus schließen, wie viel die ausgewählte Produktkom-ponente kostet, in dem er den Gesamtpreis vor der Auswahl vom aktuellen subtrahiert, imWesentlichen aber nimmt der Kunde nur den endgültigen Gesamtpreis wahr. Dass dieseArt der Preisdarstellung gar von Vorteil sein kann, zeigt eine weitere Studie in [Pol08].Diese kommt zu dem Ergebnis, dass die Kunden durchschnittlich mehr Produktkomponen-ten auswählen und diese im Preis höher liegen, wenn Gesamt- statt Aufpreise dargestelltwerden. Die Erklärung hierfür findet sich in der Prospect-Theory von Kahneman undTversky [KT79], die u. a. besagt, dass Menschen Verluste mehr fürchten, als sie Gewinnbegrüßen. Angewandt auf die Preisdarstellung bedeutet dies, dass der dargestellte Aufpreisin negativer Form wirkt, während der Gesamtpreis nicht derartig ins Gewicht fällt.

3.2.3.8 Verkaufsunterstützung

Das Ergebnis eines Konfigurationsprozesses entspricht in der Regel einer Produktzusam-menstellung. Die Folgeschritte umfassen meist die Bestellung und Bezahlung des Produk-tes. Diesbezüglich können Produktkonfiguratoren differenziert werden in ein ersetzendesund ergänzendes Verkaufssystem. Bei Ersterem ist es dem Kunde möglich, dass zusammen-gestellte Produkt sofort zu bestellen und auch zu bezahlen. Der Produktkonfigurator ent-hält dafür ein Bezahlsystem oder ist einem solchen direkt angeschlossen. Der Einsatz einesVerkäufers ist an dieser Stelle überflüssig. Als Beispiel eignet sich hierfür der bereits er-wähnte PC-Konfigurator der Firma DELL. Diese Verfahrensweise ist nicht geeignet, wenn

8http://www.amazon.de/


Produktkonfiguratoren nur als verkaufsvorbereitende Instrumente zum Einsatz kommensollen. Dies ist u. a. im Bereich der Automobilindustrie verbreitet. Der Kunde konfigurierthier das gewünschte Auto und geht mit dieser Konfiguration dann zu einem Fachhändlerseiner Wahl, der die letzten Schritte bis zur Bestellung und Bezahlung begleitet. In diesemFall spricht man von einem ergänzenden Verkaufssystem.

3.2.3.9 Visualisierung

Diese Klasse der Präsentations- und Darstellungskategorie befasst sich mit der Visualisie-rung der einem Produktkonfigurator zugrunde liegenden Informationen. In [Lec06] findetsich hierzu eine Differenzierung in die Ausprägungen der textbasierten Darstellung, derVisualisierung mit vordefinierten Grafiken oder der Visualisierung mit zur Laufzeit ge-nerierten Grafiken. In der Gegenwart umschreibt der Begriff der Visualisierung ein vielbreiteres Spektrum an Darstellungselementen (z. B. Flash-Animationen, Videos oder 3D-Objekten), sodass sich diese nicht alleine auf Grafiken bezieht. Aus diesem Grund werdenfortan die folgenden Begriffe verwendet: vordefiniertes Medium und zur Laufzeit generier-tes Medium.Die textbasierte Darstellung stellt eine eher konservative Visualisierungsform dar, die sichfür den internen Einsatz oder für den Einsatz in einem Expertenumfeld eignet. Hier ist dieVerwendung von erklärenden Medien nicht immer notwendig, sodass die reine textuelle Be-schreibung der Produktkomponenten durchaus genügt. In jedem anderen Einsatzbereichstellt der Einsatz von Medien zur Erklärung und Beschreibung eine Mindestanforderungdar. Bei der zweiten Ausprägung, der Visualisierung mit vordefinierten Medien, werdenderartige Medien im Vorfeld angefertigt und entsprechend dargestellt. Die flexibelste Va-riante allerdings wird durch die dritte Ausprägung, der Visualisierung mit zur Laufzeitgenerierten Medien, realisiert, da diese erst im Konfigurationsverlauf erzeugt werden. DerNachteil dieser Variante liegt in einem erhöhten Rechenaufwand zur Generierung der Dar-stellungselemente.

3.2.4 Klassen der Logik- und Architekturkategorie

Die vierte Kategorie der Klassifikation betrachtet die Logik und Architektur eines Pro-duktkonfigurators. Dazu werden im Folgenden die Klassen Zeitpunkt der Abhängigkeits-prüfung, Systeminteraktion, Architekturszenario und Art der Abhängigkeitsprüfung näherbetrachtet. Einen Überblick dazu gibt die Abbildung 3.5.

3.2.4.1 Zeitpunkt der Abhängigkeitsprüfung

Während des Konfigurationsprozesses tätigt der Nutzer eine Reihe von Aus- und Ab-wahlaktivitäten, durch die die Zusammenstellung des Produktes beschrieben wird. DerProduktkonfigurator muss anhand der in einem Datenmodell definierten Abhängigkeits-beschreibungen die Entscheidungen des Benutzers prüfen, damit spätestens zum Ende desKonfigurationsprozesses sichergestellt ist, dass das zusammengestellte Produkt auch her-stellbar ist. Diese Prüfung kann zu unterschiedlichen Zeitpunkten erfolgen, weshalb in dervorliegenden Arbeit die folgenden Ausprägungen differenziert werden: laufzeitbezogene,intervallbezogene und resultatbezogene Abhängigkeitsprüfung.


Logik- und

Architektur-

kategorie

Art der

Abhängig-

keitsprüfung

Architektur-

szenario

System-

interaktion

Zeitpunkt der

Abhängig-

keitsprüfunglaufzeitbezogen

intervallbezogen

resultatbezogen

online

offline

zentral

dezentral

implizite Techniken

explizite Techniken

Abbildung 3.5: Klassifikationstentakel der Logik- und Architekturkategorie

Bei der ersten Variante, der laufzeitbezogenen Abhängigkeitsprüfung, erfolgt die Prüfungnach jeder durch den Kunden erfolgten Aktivität. Dadurch wird sichergestellt, dass derKonfigurationsprozess nur einem gültigen Pfad folgt und so keine Revidierungen durchden Kunden notwendig sind. Diese Art der Prüfung erfordert insbesondere zwischen denAus- und Abwahlaktivitäten erhöhte Rechenleistung, da der Produktkonfigurator alle re-levanten Abhängigkeitsbeschreibungen zur Laufzeit zu prüfen hat. Die als intervallbezoge-ne Abhängigkeitsprüfung bezeichnete Variante entspricht einer sogenannten Intervallprü-fung. Hierbei werden bestimmte Prüfpunkte festgelegt, an denen die Abhängigkeitsprü-fung stattfindet. Prüfpunkte können anhand der Einteilung der Komponenten in diverseKategorien festgelegt werden. Beispielsweise könnte bei der Konfiguration eines Catering-Services ein erster Prüfpunkt definiert werden, wenn das Essenzielle ausgewählt wurdeund ein zweiter Prüfpunkt nach der Auswahl der Serviceleistungen. Die dritte Ausprä-gung findet sich vor allem in Produktkonfiguratoren erster Generation. In der Gegenwartspielt die als resultatbezogene Abhängigkeitsprüfung bezeichnete Ausprägung keine bedeu-tende Rolle mehr, sodass sie an dieser Stelle nur der Vollständigkeit halber erwähnt wird.Hierbei erfolgt erst nach Abschluss des eigentlichen Konfigurationsprozesses eine Prüfungder Entscheidungen des Kunden. Der Nachteil dieser Variante ist klar: falls eine ungülti-ge Entscheidung getroffen wurde, muss im schlechtesten Fall der Kunde fast die gesamteKonfiguration neu durchgehen. Ein Vergleich der drei Ausprägungen im zeitlichen Verlaufdes Konfigurationsvorgangs zeigt die Abbildung 3.6.

3.2.4.2 Systeminteraktion

Die zweite Klasse der Logik- und Architekturkategorie unterscheidet Produktkonfigurato-ren bezogen auf deren Systeminteraktion. Genauer betrachtet wird zwischen einer Online-und einer Offline-Systeminteraktion differenziert. Bei Letzterer befinden sich gemäß demMVC-Ansatz alle Module, Komponenten und Informationen auf einem System. Es findetkeine Interaktion zwischen den beteiligten Systemen über ein Netzwerk statt. Gegenteiliges


Konfigurations-

schritte1 2 3 4 5 6 7 8

laufzeitbezogen intervallbezogen resultatbezogenPrüfpunkte:

Abbildung 3.6: Gegenüberstellung verschiedener Abhängigkeitsprüfungen

ist bei der ersten Ausprägung zu benennen: Hier findet eine Interaktion zwischen verschie-denen Systemen über ein Netzwerk statt. Dabei ist es nicht von Bedeutung, ob es sichum ein internes oder externes Netzwerk handelt. Entscheidend ist vielmehr die Tatsache,dass nicht alle Bestandteile des Produktkonfigurators auf einem System abgelegt sind. Sowerden beispielsweise alle Produktkonfiguratoren, die im World Wide Web aufrufbar sind,zur Ausprägung der Online-Systeme gezählt, da hier eine Systeminteraktion zwischen zweiSystemen, im konkreten Fall also des Kunden einerseits und des Anbieters andererseits,stattfindet.

3.2.4.3 Architekturszenario

Unter der Klasse Architekturszenario lassen sich die folgenden zwei elementaren Ausprä-gungen aufführen: eine zentrale und eine dezentrale Architektur. Beide Varianten fin-den sich unter anderem auch in [Sch06] und als „Konfigurationsszenario“ bezeichnet in[Lie08]. Unter einem Architekturszenario ist hierbei zu verstehen, inwiefern die unter-schiedlichen Systeme (d. h. die Systeme des Kunden und des Anbieters) bei einer Online-Systeminteraktion verteilt sind und wie diese miteinander interagieren. In der Fachlitera-tur findet man für diese Klasse eine unterschiedliche Detailtiefe. Leckner betrachtet in[Lec06] z. B. nur die Datenhaltung; er unterteilt so in einen Online-Produktkonfiguratormit ausschließlich zentraler und einen mit lokaler Datenhaltung. Liebisch fasst hier einenweiteren Rahmen, in dem er die Verbundenheit der Clients, also der Systeme, über diedie Anwender bzw. Kunden mit dem Produktkonfigurator in Interaktion stehen, und dieLogik des Produktkonfigurators betrachtet.

Das zentrale Architekturszenario ist ihm zufolge dadurch gekennzeichnet, dass sich dieals Thin Clients bezeichneten Systeme der Kunden (in diesem Fall normale Webbrow-ser) in einer dauerhaften Verbundenheit mit einem zentralen Anwendungsserver befinden.Dadurch kann das gesamte Produktwissen und die Logik des Produktkonfigurators aufdiesem vorgehalten werden, wodurch sich die Pflege und Wartung des Datenbestandesund der Logik des Produktkonfigurators wesentlich vereinfachen. Auch für den Fall, dassErgebnisse einer auf einem Thin Client durchgeführten Konfiguration in den zentralenDatenbestand überführt werden soll, ist diese Variante von Vorteil. Durch die dauerhafteVerbundenheit mit dem zentralen Anwendungsserver können die Daten in einfacher Artund Weise transferiert werden.


Bei einem dezentralen Architekturszenario hingegen existiert keine dauerhafte Verbunden-heit zwischen den unterschiedlichen Systemen. Dadurch bedingt ergibt sich, dass auf denin diesem Szenario als Fat Clients bezeichneten Kundensystemen jeweils eine aktuelle lo-kale Kopie des Produktwissens existieren muss. Auch muss der Fat Client über eine Logikverfügen, die die Funktionalität des Produktkonfigurators realisiert. Es existiert hier alsonicht der „eine“ Produktkonfigurator auf einem zentralen System, sondern ein auf mehre-ren Systemen verteilter und dort jeweils funktional autonomer Produktkonfigurator. Einehohe Bedeutung genießt in diesem Szenario zudem eine sogenannte Replikationskompo-nente, welche anstelle des Anwendungsservers in der Gesamtsystemumgebung verankertist. Diese hat u. a. dafür Sorge zu tragen, dass die Fat Clients fortlaufend mit dem aktuellenDatenbestand versorgt werden. Auch gehört zum Aufgabengebiet dieser Komponente, dassÄnderungen an Konfigurationen, die auf einem der Fat Clients vorgenommen wurden, ingeeigneter Weise zum Hauptdatenbestand synchronisiert werden. Eine derartige Architek-tur findet man vor allem im Außendienstbereich. Ein Vertreter hat hier z. B. einen funktio-nal autonomen Produktkonfigurator auf einem Notebook installiert und verfügt über eineaktuelle Kopie des Produktwissens. Mit dieser kann er nun vor Ort bei seinem Kundendie entsprechende Konfiguration vornehmen. Der Bedarf des Einsatzes solcher Architek-turen ist jedoch mit fortlaufender Entwicklung und Verbesserung der Netz-Infrastrukturals rückläufig einzuschätzen, da ein Zugriff auf einen zentralen Anwendungsserver durchden Einsatz diverser Technologien, wie z. B. WLAN (Wireless Local Area Network), HSPA(High Speed Packet Access) oder zukünftig LTE (Long Term Evolution)9, in der Flächeund Bandbreite zunehmend möglich sein wird.

3.2.4.4 Art der Abhängigkeitsprüfung

Diese Klasse der Logik- und Architekturkategorie beschreibt die unterschiedlichen Systemebzw. Techniken, die zur Abhängigkeitsprüfung und damit zur Anwendung des Produktwis-sens eingesetzt werden können. Dabei werden die im Rahmen der Modularisierung (siehedazu Abschnitt 2.2.3) definierten Abhängigkeiten zwischen den Produktkomponenten aufderen Gültigkeit während eines Konfigurationsprozesses geprüft. Eine andere Bezeichnungfür diese Klasse findet sich im Begriff der Wissensbasis. Diese enthält das gesamte Produkt-wissen und ist nach Blecker die wichtigste technische Komponente eines Produktkonfi-gurators [BAKF04]. In Abhängigkeit zu den eingesetzten Systemen bzw. Techniken stehtauch die Art und Weise der Definition und Ablegung des Produktwissens. In der Fachli-teratur findet sich zu dieser Klasse eine unterschiedliche Anzahl an Ausprägungsstufen.Zusammenfassend aus [Sch06], [Lec06] und [Wüp00] werden im Folgenden vier Ausprä-gungen beschrieben, die in einer zweigliedrigen Struktur nach Scheer geordnet werden.Dieser differenziert implizite und explizite Arten von Techniken zur Abhängigkeitsprüfung.Implizite Techniken

Als implizit beschreibt Scheer Systeme, bei denen „nur bestimmte Problemlösungen desgesamten Konfigurationsproblems hinterlegt werden“. Derartige Techniken sind regelba-sierter, entscheidungsbaumbasierter und fallbasierter Art.Regelbasierte Systeme verwenden die am weitesten verbreitete Form der Wissensrepräsen-tation in Form von Regeln [Bec06]. Diese entsprechen formalisierten Konditionalsätzender Form „Wenn (Bedingung B ist gültig), dann (Aktion A)“. Sie bestehen demnach aus

9http://www.nomor.de/home/company/lte-demo-details


einem Bedingungs- und einem Aktionsteil. Die Bedingung B und die Aktion A entsprechenbezogen auf eine logische Interpretation Aussagen oder PL1-Formeln (Formeln Prädika-tenlogik erster Stufe). In der Systematik der regelbasierten Systeme werden die Aussagebzw. Formel innerhalb des Bedingungsteils als LHS (Left-Hand-Side) und innerhalb desAktionsteils als RHS (Right-Hand-Side) bezeichnet. Der Vorteil von regelbasierten Syste-men liegt nach Becker in der großen Nähe zum menschlichen Denken. So werden z. B.Konditionalsätze durch den Menschen benutzt, um Handlungsanweisungen oder Progno-sen auszudrücken. Ein Beispiel im Sinne der Produktkonfiguration lässt sich wie folgtkonstruieren: Das Schaltsystem eines Autos kann z. B. einer Gangschaltung G oder ei-ner Automatikschaltung A entsprechen. Davon abhängig erfolgt dann die Auswahl einesSchalthebels vom Grundtyp G oder A. Eine Regel kann dann wie folgt formuliert werden:Wenn der Kunde eine Gangschaltung (dies entspricht der Bedingung) auswählt, so gilt dieProduktkomponente Schalthebel des Grundtyps G fortan als Implikativkomponente (diesentspricht dann der Aktion).

Die zweite den impliziten Techniken zugeordnete Variante nutzt die Methodik der Ent-scheidungsbäume. Diese sind eine kompakte Darstellung eines Satzes logischer Regeln, wiesie bereits im Sinne der regelbasierten Systeme erklärt wurden. Auch aus diesem Grundsind sie für den Menschen leicht verständlich [Cim08]. Der Aufbau eines Entscheidungs-baums ist in Abbildung 3.7 für das bereits angewandte Beispiel dargestellt. Die Knotenwerden hierbei mit der Bezeichnung der jeweiligen Klasse bezeichnet. In dem gewähl-ten Beispiel entspricht dies der Klasse „Schaltsysteme“. Diese hat die zwei Ausprägungen„Gangschaltung G“ und „Automatikschaltung A“, welche als Sohnknoten dem Vaterkno-ten zugeordnet werden. Unterhalb jeder Ausprägung findet man dann die möglichen Va-rianten der jeweiligen Schalthebel, die in einem Konfigurationsprozess gewählt werdenkönnen.

Schaltsysteme

Gangschaltung GAutomatik-

schaltung A

Schalthebel G1 Schalthebel G2 Schalthebel A1

Abbildung 3.7: Beispielbezogener Entscheidungsbaum

Eine weitere implizite Technik bilden die fallbasierten Systeme. Hierbei werden bereitsdurchgeführte und abgeschlossene Konfigurationen persistiert. Bei einer neuen Konfigura-tion werden die persistierten Zusammenstellungen dann durchsucht und bei vorhandenerÄhnlichkeit auf das gegebene Konfigurationsproblem angewendet. Die Ähnlichkeit wirdhierbei mittels eines sogenannten Ähnlichkeitsmaßes bestimmt.

Explizite Techniken


Als explizit werden Techniken bezeichnet, bei denen alle Konfigurationsmöglichkeiten ineinem (generischen) Produktmodell abgebildet werden [Sch06]. Das gesamte Produktwis-sen ist demnach in einer bestimmten Weise aufbereitet und für den Produktkonfiguratorles- und anwendbar. Unterschieden werden kann hierbei u. a. in die constraint-, objekt-und entscheidungstabellenbasierten Techniken, wovon Erstere im Folgenden exemplarischbetrachtet wird.Die constraintbasierten Techniken nutzen zur Lösung eines Konfigurationsproblems dasProduktwissen einerseits (d. h. in diesem Fall die konkreten Produktkomponenten samtihrer Eigenschaften) und das sogenannte Kontrollwissen andererseits. Letzteres entsprichthierbei den Constraints. Diese repräsentieren die Abhängigkeitsbeschreibungen zwischenden einzelnen Produktkomponenten. Constraints lassen sich als mindestens zweidimen-sionale Matrix darstellen, in der die Abhängigkeiten durch Wertbelegungen symbolisiertwerden. Für das bereits bekannte Beispiel gilt hier: Die zwei Ausprägungen der Schalt-systeme werden auf der Dimensionsachse X abgetragen und die weiteren Ausprägungenentsprechend auf der Dimensionsachse Y. Die Abhängigkeiten werden durch Belegungenin der entsprechenden Dimensionskreuzung abgebildet. Zur Veranschaulichung dient dieAbbildung 3.8.

Gangschaltung G

Automatikschaltung A

Sch

alt

heb

el G

1

Sch

alt

heb

el G

2

Sch

alt

heb

el A

1

Dim

ensi

on

X

Dimension Y

X X

X

Abbildung 3.8: Beispielbezogener Constraint

Hieraus wird bereits ersichtlich, dass die wesentliche Aufgabe der Constraints in der Über-prüfung der Konsistenz der aktuellen Konfiguration besteht. Diese ist genau dann gül-tig, wenn alle Constraints erfüllt sind. Für weiterführende Details zur constraintbasiertenTechnik sei auf [Run06] verwiesen.

3.3 Datensemantische Klassifikation

Die im ersten und zweiten Abschnitt beschriebene Globalklassifikation betrachtete denProduktkonfigurator als zentrales Klassifikationsobjekt. Einen anderen Ansatz stellt dage-gen die datensemantische Klassifikation nach Liebisch dar [Lie08], die in diesem Abschnittin erweiterter Fassung vorgestellt wird. Hier stehen die Daten, die im Produktkonfiguratorihre Anwendung finden, im Vordergrund. Die datensemantische Klassifikation hat folglichsämtliche den Produktkonfigurator berührende Informationen zum zentralen Bezugsob-jekt. Im Fortlauf der Arbeit werden Bezüge auf die entsprechenden Klassen genommen,weshalb sie nun, wie in der Abbildung 3.9 als Klassifikationstentakel dargestellt, erklärtwerden.

3.3. DATENSEMANTISCHE KLASSIFIKATION 59

Datenarten in

Produkt-

konfiguratoren

Integrations-

daten

Modelldaten

Administra-

tionsdaten

Oberflächen-

daten

Konfigurations-

daten

Verkehrsdaten

globale

lokale

Abbildung 3.9: Klassifikationstentakel zur Datensemantik in Produktkonfiguratoren

3.3.1 Modelldaten

Unter dieser Klasse werden alle Informationen zusammengeführt, die die Produktkompo-nenten beschreiben und charakterisieren. Dazu zählen neben den reinen textuellen Be-schreibungen auch sämtliche zur Visualisierung vorgesehene Medien. Auch die Wertbe-legungsmöglichkeiten für die Eigenschaften der Produktkomponenten wie auch die Ab-hängigkeitsbeschreibungen werden hier zugeordnet. Die Klasse der Modelldaten umfasstfolglich das gesamte zur Verfügung stehende Produktwissen.

3.3.2 Oberflächendaten

Alle Daten, die im Sinne der View-Ebene des MVC-Ansatzes die äußere Form und Dar-stellung eines Produktkonfigurators bestimmen, werden zur Klasse der Oberflächendatengezählt. Dies sind u. a. Farbcodierungen, Layout- und Stylesheet-Definitionen, Beschriftun-gen für Interaktionselemente (z. B. interaktive Schaltknöpfe), Hinweistexte zur Nutzungdes Produktkonfigurators (z. B. sogenannte Tool-Tipps) oder anbieterbezogene Darstel-lungselemente (z. B. Firmen- oder Markenlogo).

3.3.3 Konfigurationsdaten

Liebisch versteht unter Konfigurationsdaten „alle in der Interaktion zwischen Anwenderund Konfigurator relevanten Daten“. Er benennt hierzu u. a. durch den Kunden abgespei-cherte Konfigurationen und kundenbezogene Informationen, die im Falle einer Bestellungoder einer Angebotserstellung abgefragt und erfasst werden [Lie08]. Im Rahmen dieser Ar-beit werden die Konfigurationsdaten in einem engeren Sinne betrachtet: Sie entsprechen


einzig den Daten, die während eines Konfigurationsprozesses generiert wurden und letzt-lich das Konfigurationsergebnis charakterisieren. Im Grunde genommen entsprechen siealso dem Ergebnis einer Produktzusammenstellung in Form aller für eine Rekonstruktionder Konfiguration erforderlichen Informationen.

3.3.4 Verkehrsdaten

Die Klasse der Verkehrsdaten umfasst alle Daten, die neben den Konfigurationsdaten zwi-schen dem Kunden und dem Produktkonfigurator während eines Konfigurationsprozessestransferiert werden. Hierunter sind u. a. die erfassten kundenbezogenen Informationen zuzählen, die bei Liebisch den Konfigurationsdaten zugeordnet werden, aber auch alle Da-ten, die z. B. Auskunft über den Ort und die Zeitzone des Kunden geben. Auch derartigefür eine Identifizierung des Kunden hilfreichen Informationen, wie z. B. die IP- oder MAC-Adresse des Kunden, die aus technischer Sicht zweifelsfrei erfasst werden können, werdenzur Klasse der Verkehrsdaten gezählt. Der Gesamtheit dieser Daten ist gleich, dass siewährend der Interaktion der Gefahr ausgesetzt sind, von Dritten abgehört zu werden. Ausdiesem Grund kommt der Sicherheit der Verkehrsdaten mit Blick auf die Datenschutz-richtlinien eine enorme Bedeutung zu.

3.3.5 Administrationsdaten

Administrationsdaten lassen sich nach dem Kerngedanken der datensemantischen Klassi-fikation nach Liebisch definieren als „organisatorisch als auch technisch notwendige In-formationen für den Betrieb eines Produktkonfigurators“ [Lie08]. Hierdurch werden u. a.Berechtigungen für Mitarbeiter definiert bis hin zur Aufstellung komplexer Rechteverwal-tungssysteme. Auch Zugangsdaten zu DBMS oder anderweitigen Speicherungssystemenwerden zu dieser Klasse gezählt.

3.3.6 Integrationsdaten

Eine weitere Klasse, die nicht Bestandteil der datensemantischen Klassifikation nach Lie-bisch ist, trägt die Bezeichnung der Integrationsdaten. Hierbei wird in zweierlei Artendifferenziert: globale und lokale Integrationsdaten. Erstere umfassen alle Daten, die durcheine Integration in einen Produktkonfigurator gelangen oder durch diesen in angekoppel-te Systeme verteilt werden. So können z. B. auch Modelldaten oder Konfigurationsdatenein Teil der globalen Integrationsdaten sein. Anders sieht es dagegen bei den lokalen In-tegrationsdaten aus. Hierunter werden Daten gezählt, welche die Integration der unter-schiedlichen Systeme spezifizieren, wie z. B. Schnittstellenbeschreibungen oder technischeAnforderungen für die Integration eines externen Programms in einen Produktkonfigura-tor.Es gibt darüber hinaus weitere Möglichkeiten und Ansätze zur Aufstellung einer datense-mantischen Klassifikation. Die Charakteristik dieser ist hierbei vor allem davon abhängig,in welchem Gesamtsystemumfeld der betrachtete Produktkonfigurator eingesetzt wird, so-dass durchaus weitere Klassen gebildet werden können, die an dieser Stelle nicht aufgeführtsind.

Kapitel 4

Integratives Grundmodell

Entsprechend dem Titel der vorliegenden Arbeit stellt dieses Kapitel ein integrativesGrundmodell für Produktkonfiguratoren vor. Dazu werden im Folgenden zunächst derBegriff des integrativen Grundmodells erläutert und die Vorgehensweise zum Entwurf desselbigen beschrieben. Darauf basierend erfolgt die Beschreibung der enthaltenen Moduleund die Betrachtung der Modulabhängigkeiten. Im weiteren Fortlauf wird das integrativeGrundmodell einer Anforderungs- und Anwendungsvalidierung unterzogen. Das Kapitelschließt mit der Vorstellung von verschiedenen Synergieeffekten ab.

4.1 Definition

Der Begriff des Modells lässt sich zurückführen auf das lateinische Wort modulus („Maß“,„Maßstab“), aus dem das italienische Wort modello, welches sinngemäß für „Muster“ oder„Vorbild“ steht, hervorgegangen ist. Er gehörte bis in das 18. Jahrhundert vor allem demsprachlichen Duktus der bildenden Künstler an [Hei04]. In der Gegenwart findet der Be-griff eine weitreichende Verwendung in zahlreichen Wissenschafts- und Gesellschaftsbe-reichen. Dadurch bedingt haben sich unterschiedliche Deutungsweisen herausgebildet, diesich auch in den existierenden Modelltypen widerspiegeln, wie z. B. dem mathematischenModell, den Modellen der Wissenschaftstheorie oder dem in der Informatik bekanntenReferenzmodell. Diese Varianz belegt zudem, weshalb eine allgemeingültige Definition desModellbegriffes nur bedingte Anwendung findet.

Vorhandene Definitionsansätze sind meist vielmehr system- oder bereichsbezogener Art.Ein Beispiel für eine derartige Definition ist in der Richtlinie mit der Nummer 3633 desVDI (Verein Deutscher Ingenieure) [VDI00] zu finden: „Ein Modell ist eine vereinfachteNachbildung eines geplanten oder real existierenden Originalsystems mit seinen Prozes-sen in einem anderen begrifflichen oder gegenständlichen System. Es unterscheidet sichhinsichtlich der untersuchungsrelevanten Eigenschaften nur innerhalb eines vom Untersu-chungsziel abhängigen Toleranzrahmens vom Vorbild.“ Einen abstrakteren Definitionsan-satz wählt Minsky in [Min68], indem er formuliert: „To an observer B, an object A* is amodel of an object A to the extent that B can use A* to answer questions that interesthim about A“. Darüber hinaus kann ein Modell nach Thomas auch als System im Sinneeiner „Zusammenfassung mehrerer Elemente [aufgefasst werden], die in irgendeiner, aberbestimmten Weise miteinander in Beziehung stehen, wobei es durch seine Funktionalität

61

62 KAPITEL 4. INTEGRATIVES GRUNDMODELL

eine als Ganzes aufzufassende Einheit darstellt, mit offenen, teilweise geschlossenen odervollständig geschlossenen Grenzen zu seiner Umwelt“ [Tho02].Bereits an dieser Stelle werden zentrale Eigenschaften eines Modells offensichtlich, diesich auch in den drei Merkmalen eines Modells nach der Modelltheorie von Stachowiakwiderspiegeln [Sta74]:

• Merkmal der Abbildung„Modelle sind stets Modelle von etwas, nämlich Abbildungen, Repräsentationen na-türlicher oder künstlicher Originale, die selbst wieder Modelle sein können.“

• Merkmal der Verkürzung„Modelle erfassen im Allgemeinen nicht alle Attribute des durch sie repräsentier-ten Originals, sondern nur solche, die den jeweiligen Modellerschaffern und/oderModellbenutzern relevant erscheinen.“

• Merkmal der Pragmatik„Modelle sind ihren Originalen nicht per se eindeutig zugeordnet. Sie erfüllen ihreErsetzungsfunktion für bestimmte - erkennende und/oder handelnde, modellbenut-zende - Subjekte, innerhalb bestimmter Zeitintervalle und unter Einschränkung aufbestimmte gedankliche oder tatsächliche Operationen.“

Zur Verdeutlichung des Zusammenhangs zwischen einem Modell, dem Original, der Um-welt sowie allen Eigenschaften und Attributen dient die folgende Abbildung 4.1.

Original Modellwird abgebildet in

Umweltwird entnommen aus

Eigenschaften/

Attribute der

Umwelt

Eigenschaften/

Attribute des

Originals

sind Bestandteil der werden abstrahiert in

Modelle

Eigenschaften/

Attribute des

Modells

Abbildung 4.1: Zusammenhang zwischen einem Modell, dessen Original und der Umwelt

Der Begriff des Grundmodells ist in dieser Arbeit als ein abstrahiertes Referenzmodellzu verstehen, welches, basierend auf den vorgenannten Begriffserklärungen, das Objektdes Produktkonfigurators als Grundlage hat. Die Charakteristik des Referenzmodells istdabei idealtypischer Natur, d. h. ein derartiges Modell bildet eine theoretische Basis fürKonstruktionen oder spezialisierte Weiterentwicklungen. Zudem dient das Referenzmodellals Vergleichsobjekt mit Blick auf andersartige Modelle, die das gleiche Modellierungsob-jekt zur Betrachtung haben.Den integrativen Aspekt erfährt das Grundmodell durch die Charakteristik eines offenenSystems. Hiermit ist gemeint, dass das Objekt Produktkonfigurator nicht als geschlossenesautonomes Anwendungssystem fungiert, sondern dass auch die Informationen, die denProduktkonfigurator ausgehend von externen Anwendungen berühren, einbezogen werden.Die drei genannten Merkmale eines Modells nach [Sta74] gelten entsprechend.

4.2. VORGEHENSWEISE 63

4.2 Vorgehensweise

Durch die Abstraktion eines Originals samt seiner Eigenschaften und Attribute hin zueinem Modell bedarf es eines strukturierten Prozesses, der als Modellierung oder Modell-bildung bezeichnet wird. Dieser iterative Prozess kann in verschiedene Schritte unterteiltwerden. Im Rahmen dieser Arbeit dient dabei die in Abbildung 4.2 dargestellte Unter-teilung nach [Gli05] als Basis, deren Schritte im weiteren Fortlauf erläutert werden.

ReflexionInformations-

gewinnungBeschreibung Validierung

Abbildung 4.2: Schritte der Modellierung in Anlehnung an [Gli05]

Der erste Schritt der Modellierung trägt die Bezeichnung Reflexion. Der Schwerpunktliegt hierbei auf der mentalen Erfassung des Modellierungsgegenstandes, d. h. es wird dieFrage geklärt, was genau durch diesen iterativen Prozess modelliert werden soll und welcheDetails und Besonderheiten es dabei zu beachten gilt. Glinz beschreibt dies auch als die„Pragmatik des Modells“. Die Reflexion legt demnach die Basis für den weiteren Verlaufund die Qualität der Modellierung.Der zweite Schritt dient der Informationsgewinnung. Neben der als Hauptaufgabe zu nen-nenden Literaturrecherche und dem Herausarbeiten von Informationen über den Model-lierungsgegenstand erfolgen in diesem Schritt auch analysierende und bewertende Tätig-keiten. So muss zum Beispiel zeitnah geprüft werden, inwieweit gefundene Informationenfür die Modellierung relevant sind oder nicht. Zudem erfolgt eine weitergehende Konkre-tisierung des Modellierungsobjektes, da aufgrund der breiteren Informationsbasis weitereDetails und Merkmale des Objektes diskutiert werden müssen, inwieweit diese Bestandteildes späteren Modells sein sollen.Nach Abschluss der Informationsgewinnung müssen die relevanten Daten in eine Ordnungüberführt werden. Dies erfolgt im Schritt der Beschreibung. Die Informationen werden dazuaufbereitet, strukturiert und auch bewertet. Zudem wird das Ergebnis der Modellierung,das Modell selber, an dieser Stelle beschrieben, konzeptuell gestaltet und formuliert. Imvierten Schritt, der Validierung, schließt sich eine Überprüfung des aufgestellten Modellshinsichtlich der in der Reflexion aufgestellten Anforderungen und Bedingungen an. In Ab-hängigkeit des Validierungsergebnisses kann es im Anschluss daran zu einer Neuaufnahmeder ersten beiden Schritte kommen.Der in seiner Unterteilung soeben beschriebene Prozess der Modellbildung kann in Be-zug auf die Gewinnung der dem Modell zugrunde liegenden Informationen unterschiedenwerden in die

• strukturelle,

• pragmatische und

• die strukturell-pragmatische


Modellbildung. Erstere zeichnet sich dadurch aus, dass von einem bekannten Objekt ausder Umwelt (z. B. wie in dieser Arbeit ein Produktkonfigurator) eine Abstraktion erfolgt.Das Modell stützt sich also auf direkt gewonnene Informationen, da die innere Struktur undArbeitsweise des Objektes bekannt ist. Es werden bewusst Schlüsse gezogen und Erkennt-nisse extrahiert. Das Gegenteil hierzu stellt die pragmatische Modellbildung dar. Die innereStruktur des Objektes ist hier nicht bekannt, sodass sich nur anhand einer Verhaltens- undFunktionsanalyse (z. B. Tests, Simulationen oder Belastungstests) Schlüsse und Erkennt-nisse über die innere Struktur des Objektes ziehen lassen. In der Regel handelt es sichhierbei also um eine Informationsgewinnung auf Basis von Beobachtungen und Progno-sen. Eine Verschmelzung der beiden Formen stellt die dritte Form der Modellbildung, diestrukturell-pragmatische, dar. Hierbei gibt es sowohl Bereiche, in denen eine direkte In-formationsgewinnung möglich ist, als auch solche Bereiche, in denen die Einblicke in dieinternen Verfahrensabläufe verwehrt bleiben.Der Entwurf des integrativen Grundmodells (siehe dazu Abschnitt 4.3) basiert im Wesent-lichen auf dem soeben beschriebenen Prozess der Modellbildung. Es handelt sich dabei umeine strukturell-pragmatische Modellbildung, da ein Blick auf die internen Mechanismender untersuchten Produktkonfiguratoren und deren in Abhängigkeit stehenden Teilobjektenicht in jeder Hinsicht möglich ist. Die Ursache hierfür ist trivial: Es besteht keine Not-wendigkeit und auch kein Interesse seitens der Anbieter von Produktkonfiguratoren an derVeröffentlichung des eigenen Programmcodes.Im ersten Schritt der eigentlichen Modellbildung wurde so der wirtschaftliche und betrieb-liche Kontext betrachtet, in dem sich das Modellierungsobjekt des Produktkonfiguratorsbefindet. Aufbauend auf dieser Analyse wurde eine Eingrenzung der Systemobjekte undInformationseinheiten vorgenommen, die im Sinne eines integrativen Grundmodells eineRelevanz vorweisen können. Zur Informationsgewinnung wurde dann eine umfangreicheLiteraturrecherche durchgeführt, die durch die Beobachtung und Analyse diverser Pro-duktkonfiguratoren mit praktischem Anwendungswissen erweitert wurde. Als ein Teiler-gebnis der Informationsgewinnung ist z. B. die in Kapitel 3 vorgestellte Globalklassifikationvon Produktkonfiguratoren zu nennen. Zur Beschreibung und Formulierung des Modellswurde zudem der bereits aus früheren Abschnitten bekannte MVC-Ansatz herangezogen.Der Prozess der Modellbildung wird in den Abschnitten 4.4.1 und 4.4.2 im Sinne einerAnforderungs- und Anwendungsvalidierung abgeschlossen.

4.3 Module und Architektur

In diesem Abschnitt erfolgt eine detaillierte Erklärung und Beschreibung des integrativenGrundmodells für Produktkonfiguratoren. Hierzu wird in einem ersten Unterabschnittdas Grundmodell als Ganzes beschrieben und dabei auf die Merkmale und Funktionender enthaltenen Module eingegangen. Anschließend werden die Modulabhängigkeiten undDatenzugriffe im Sinne der datensemantischen Klassifikation (siehe hierzu Abschnitt 3.3)dargestellt.

4.3.1 Module des integrativen Grundmodells

Das in dieser Arbeit vorliegende integrative Grundmodell ist modular aufgebaut. Hiermitist gemeint, dass es in einzelne Bestandteile zerlegt werden kann und somit die zentralen

4.3. MODULE UND ARCHITEKTUR 65

Funktionen unterschiedlichen Modulen zugeordnet sind. Ein Schema dieses Modells findetsich in der folgenden Abbildung 4.3 wieder.

Inferenzwerk

Pflegesystem

Integrator C

Interaktions-

werk

Dialogwerk

SteuerungBerechtigungs-

system

Aktivitäten-

protokollierungs-

system

Datenaufbe-

reitungssystem

Oberflächendaten

Modelldaten

Administra-

tionsdaten

Konfigurations-

daten

Integrator B

Mitarbeiter-

stammdaten

Produkt-

informationssysteme

Integrator A

Kunden-

informationssysteme

Verkehrsdaten

Model-Ebene

(interne Daten)

Module der

Controller-Ebene

Module der

View-Ebene

externe Daten

optional; nur bei dezentraler Architektur

Zugriffsrichtungbeidseitige Implementierungsabhängigkeit

Datenver-

teilungssystem

optional; Zugriffsrichtung

Abbildung 4.3: Schema des integrativen Grundmodells

Der Vorteil der Modularität eines derartigen Systems, wie das Modell als Ganzes nachThomas (siehe dazu Abschnitt 4.1) bezeichnet werden kann, liegt u. a. in der flexiblenErweiterbarkeit und der vereinfachten Wartung. Im Falle von letzterem können Moduleaus dem aktiven System zeitweise herausgenommen oder gegen identische Module ersetztwerden, solange die Wartung einer Einheit andauert. Auch in Bezug auf die Skalierbar-


keit erlaubt die Modularität zeitnahe Anpassungsoptionen, die bei einem monolithischenSystem so nicht möglich wären. Ebenso hinsichtlich des Modellbildungsprozesses erleich-tert die Modularität die Bildung von Funktionseinheiten und führt so zu einer besserenVerständlichkeit des Gesamtsystems.

Das hier vorgestellte Grundmodell umfasst zwölf Module, darüber hinaus fünf interne unddrei externe sowie vier intern gekoppelte Persistierungselemente. Unter dem Begriff einesPersistierungselementes ist hierbei eine Datenbank oder aber eine Ansammlung von Da-teien zu verstehen (siehe hierzu auch Abschnitt 3.2.2.4). Die konkrete Form wird in derentsprechenden Modulbeschreibung benannt. Die in der Abbildung 4.3 ersichtlichen dreiModule mit der Bezeichnung Integrator A, B und C werden in der weiteren Beschreibungals ein Modul betrachtet, da diese drei dem Typ des Integrator-Moduls entsprechen. Außer-dem werden die Module und Persistierungselemente gemäß der Zuordnung zu den Ebenendes MVC-Ansatzes im Schema des integrativen Grundmodells mit unterschiedlicher Dar-stellungsform gruppiert. Auch enthält diese Abbildung die Modulabhängigkeiten im Sinneder Zugriffsrichtung und die Datenzugriffe der Module auf die Persistierungselemente, diejeweils in den Unterabschnitten 4.3.2 und 4.3.3 näher betrachtet werden.

4.3.1.1 Model-Ebene

Die Model-Ebene umfasst in diesem Grundmodell die unterschiedlichen Persistierungsele-mente. Wie bereits erwähnt, erfolgt hierbei eine Differenzierung in interne, intern gekop-pelte und externe Persistierungselemente. Erstere sind ein fester Bestandteil des Grundmo-dells und interagieren mit der Mehrzahl der Module in direkter Art und Weise. Sie stellendas zentrale Wissen des Produktkonfigurators in jeglicher Hinsicht dar. Als Beispiele hier-für seien die Produktdaten samt zugehöriger Abhängigkeitsbeschreibungen (Modelldaten)oder die Informationen über das „Aussehen“ des Produktkonfigurators (Oberflächenda-ten) zu nennen. Als intern gekoppelt werden solche Persistierungselemente bezeichnet, dieBestandteil eines Moduls sind. Im Rahmen dieser Arbeit betrifft dies die lokalen Integrati-onsdaten. Externe Persistierungselemente sind in der Systemumgebung des Unternehmensbzw. Anbieters angesiedelt und werden nicht direkt dem Wirkungskreis des Grundmodellszugeordnet. Sie enthalten jedoch Daten, die für einen Produktkonfigurator in unterschied-licher Ausprägung relevant sein können (z. B. betriebliche Kundendaten). Bezogen aufden integrativen Charakter des Grundmodells werden die externen Persistierungselementedaher in der abstrahierten Abbildung aufgeführt.

Eine Übersicht für die Zuordnung der unterschiedlichen Informationsarten zu den jeweili-gen Arten der Persistierungselemente bietet die Tabelle 4.1. Für eine detailliertere Be-schreibung der aufgeführten Vertreter empfiehlt sich der Abschnitt 3.3 dieser Arbeit.

4.3.1.2 View-Ebene

Der View-Ebene wird das Interaktionswerk als einziges Modul des Grundmodells zugeord-net. Dieses wird im Folgenden näher betrachtet.

Der hohe Stellenwert des Moduls mit Blick auf das Grundmodell wird anhand der For-mulierung seiner Aufgaben deutlich: Einerseits liegt die Aufgabe in der Interpretationder Style-Definitionen zum äußeren Erscheinungsbild und deren Generierung; andererseits


Art Persistierungselement Beispielintern Modelldaten Abhängigkeitsbeschreibung

Oberflächendaten Farbcodierung, MenütexteAdministrationsdaten Zugangsdaten, BerechtigungenKonfigurationsdaten gespeicherte KonfigurationVerkehrsdaten Session-ID

intern gekoppelt lokale Integrationsdaten Schnittstellenbeschreibungextern Produktinformationssysteme Produktbeschreibung

Kundeninformationssysteme KundennummerMitarbeiterstammdaten Mitarbeiter-PNR

Tabelle 4.1: Zuordnung der Persistierungselemente

gehören die Entgegennahme der Eingabeaktivitäten des Benutzers und der für die Weiter-verarbeitung notwendigen Transformationen zur Funktionalität. Zum Verständnis dientdas folgende Beispiel: Ein Benutzer wählt in einem Konfigurationsprozess eine bestimmteProduktkomponente per Klick aus. Das Interaktionswerk erfasst nun diese Aktivität desBenutzers (also den Klick) und gibt die daraus resultierenden Erkenntnisse an die ent-sprechenden Module weiter, sodass diese über die Benutzereingabe informiert sind. DieWeitergabe erfolgt hierbei mittels einer Transformation. Die Information über den Klickwird sozusagen auf eine für die Module verständliche Sprache abgebildet. So kann z. B.der Ausdruck „add(2341)“ bedeuten, dass der Benutzer die Produktkomponente mit derID 2341 angeklickt und damit für die aktuelle Konfiguration selektiert hat.

Das Interaktionswerk kann somit auch als „Schnittstelle“ oder „Interaktionsbrücke“ zwi-schen dem Produktkonfigurator und dem Benutzer bzw. Mitarbeiter bezeichnet werden.Die Funktionalität des Interaktionswerkes ist in der schematischen Darstellung in Abbil-dung 4.4 zusammengefasst.

z.B. Thin ClientSystem

Interaktionswerk

Style-

Definitionen

Design-

Interpretation

Benutzer-

eingaben

transformierte

Weiterleitung

Abbildung 4.4: Funktionalität des Interaktionswerkes

4.3.1.3 Controller-Ebene

Ein Großteil der Module des integrativen Grundmodells findet sich in der nach dem MVC-Ansatz genannten Controller-Ebene wieder. Im Detail sind dies die Module Pflegesystem,Dialogwerk, Steuerung, Integrator, Berechtigungssystem, Inferenzwerk, Aktivitätenproto-kollierungssystem, Datenaufbereitungs- und Datenverteilungssystem, welche im Folgendeneiner genaueren Betrachtung unterzogen werden.


Pflegesystem

Das Modul Pflegesystem ist für die Modifizierung von Informationen zuständig. Hierbeiist zu beachten, das unterschiedliche Benutzertypen (z. B. Mitarbeiter oder Entwickler)das Modul verwenden, was sich auf das breite Aufgabenspektrum des Pflegesystems aus-wirkt. Die Modifizierung bezieht sich dabei zum einen auf Daten, mit deren Hilfe sich dasäußere Erscheinungsbild des Produktkonfigurators definieren lässt. Ein Benutzer hat sodie Möglichkeit, entsprechende Zuordnungen zwischen Interaktionselementen (z. B. einenSchaltknopf oder eine Textzeile) und den Stylesheet-Definitionen festzulegen. Auch kannüber dieses Modul die strukturelle Gestaltung der gesamten grafischen Oberfläche vorge-nommen werden. Die folgende Abbildung 4.5 verdeutlicht die Aufgabe des Moduls undzeigt ein Beispiel für eine strukturelle Aufteilung einer grafischen Oberfläche.

Oberfläche

Pflegesystem

strukturelle Aufteilung

Abbildung 4.5: Aufgabe des Pflegesystems

Die zentrale Funktionalität des Pflegesystems entspricht der Modifizierung von Modell-daten. Das Modul ermöglicht so dem Mitarbeiter die Pflege der gesamten Daten, die zuden im Produktkonfigurator angebotenen Produkten und Komponenten vorliegen. Auchkönnen mit Hilfe des Moduls die Abhängigkeitsbeschreibungen festgelegt und Wertbele-gungsmöglichkeiten für die Komponenten definiert werden.Das Modul hat notwendigerweise einen integrierten Mechanismus, der die Zugriffsberech-tigung zur Abfrage und Modifizierung aller Informationen regelt, welche sich in den Per-sistierungselementen „Oberflächendaten“ sowie „Modelldaten“ befinden. Der Zugriff aufdas Modul erfolgt autorisierend, d. h. nur berechtigte Mitarbeiter haben die Möglichkeit,die spezifischen Funktionen des Moduls auszuführen.

Dialogwerk

Ein wichtiges Instrument zur verständlichen und erfolgsversprechenden Interaktion zwi-schen dem Produktkonfigurator und dem Benutzer stellt das Modul Dialogwerk dar. Es istzum einen für die Generierung sämtlicher ereignisbezogener Texte verantwortlich. Mittelsdieser Texte wird beispielsweise der Benutzer in einem Konfigurationsprozess abhängigder Art des Produktkonfigurators gefragt, welche Komponenten in das spätere Produkteinfließen sollen und welche Sonderwünsche seinerseits bestehen. Auch zählen Fehlermel-dungen, diverse Benutzerhinweise und Empfehlungen (bei Vorhandensein eines entspre-chenden Moduls zur Generierung von Defaults) dazu. Die konkrete Ausprägung diesesModuls ist hierbei abhängig von den Eigenschaften des Produktkonfigurators, etwa der


Visualisierung oder dem Konfigurationsverlauf (siehe hierzu Abschnitt 3.2.3). Einen in-teressanten Aspekt stellt die semantische Betrachtung der zu generierenden Texte dar,weshalb dieses Modul in Bezug auf dessen technische Umsetzung komplexer Natur seinkann.

Zum anderen hat das Dialogwerk einen organisatorisch-verwaltenden Auftrag. Hiermit istgemeint, dass es z. B. Informationen über Benutzereingaben, die durch das Interaktions-werk übermittelt werden, verarbeitet und an die angebundenen Module weiterleitet. Essorgt so für eine Symbiose des Wissens des Inferenzwerkes mit den Eingaben des Benutzersund dem Wortschatz des Produktkonfigurators und ist damit ein entscheidender Faktorfür die Güte eines Produktkonfigurators.

Steuerung

Der modulare Aufbau des integrativen Grundmodells erfordert eine zentrale Einheit zurVerwaltung aller im Modell enthaltenen Module und notwendigen Steuerungsinformatio-nen. Diese Aufgabe übernimmt das Modul Steuerung. Vergleicht man die Charakteristikdieses Moduls mit den im Abschnitt 2.3.3 vorgestellten Ansätzen zur Integration von An-wendungen in ein bestehendes System, so lässt sich das Modul wie folgt metaphorischinterpretieren: Im Kontext einer EAI stellt dieses Modul den zentralen Bus dar, an wel-chem sich die restlichen Module des Gesamtmodells „anmelden“ (siehe hierzu auch dieAbbildung 4.6). Hiermit ist gemeint, dass das Steuerungsmodul über jedes in einemProduktkonfigurator enthaltene Modul informiert ist und entsprechende Kenndaten zurVerfügung hat (z. B. Kompatibilitätsinformationen mit Blick auf die Integration weite-rer Module). Auch erfolgt über das Steuerungsmodul die Einbindung externer Module,Komponenten und Programmbereiche im Sinne der Anwendungsintegration. Neben die-ser zentralen Aufgabe enthält das Modul Informationen über die Funktionsfähigkeit desGesamtsystems einerseits und der einzelnen Module andererseits. Zur Überprüfung vonLizenzen und Aktualisierungsintervallen zum Einspielen von Updates zeichnet sich dasSteuerungsmodul ebenso verantwortlich. Der Zugriff erfolgt autorisierend.

Inferenzwerk

PflegesystemInteraktions-

werkDialogwerk

Steuerung

Berechtigungs-

system

Aktivitäten-

protokollierungs-

system

Integrator

Daten-

aufbereitungs-

system

Daten-

verteilungs-

system

externe

Module

Abbildung 4.6: Modul Steuerung im EAI-Kontext


Integrator

Das Modul Integrator ist für die Gewährleistung des integrativen Charakters des Grund-modells verantwortlich. Es ist das zentrale Element zur Einbindung externer, für den Pro-duktkonfigurator relevanter, Informationen. Es dient aber auch umgekehrt der Verteilungvon Daten aus dem Wirkungskreis des Produktkonfigurators zu den jeweiligen angebun-denen Informationssystemen des Unternehmens. Aus diesem Blickwinkel heraus kann derIntegrator auch als „Tracker“ und „Distributer“ bezeichnet werden. Das Modul arbeiteteigenständig und bedarf keines Eingreifens durch einen Mitarbeiter. Es ist zudem eines vonzwei Modulen, welches über ein intern gekoppeltes Persistierungselement verfügt. Diesesist erforderlich, da der Integrator zu jedem angekoppelten Informationssystem über dieArt und Funktionsweise der Schnittstellen informiert sein muss. Die Wartung derartigerBeschreibungen erfolgt über das zentrale Steuerungsmodul.

Berechtigungssystem

Das Modul Berechtigungssystem realisiert die Autorisierung von Mitarbeitern. Es stelltsomit ein sicherheitsrelevantes Modul dar, welches direkt an das Steuerungsmodul an-geschlossen ist. Die Funktionsweise des Berechtigungssystems ist dabei einfach: Es be-antwortet anhand vorliegender Mitarbeiterkennungen und Passwörter die Frage, ob einMitarbeiter eine bestimmte Funktion eines spezifischen Moduls ausführen darf (z. B. dasÄndern einzelner Abhängigkeitsbeschreibungen bei einer Produktkomponente). Das Mo-dul eignet sich zudem auch für die im Abschnitt 3.2.2.3 erwähnte Ausprägungsart derIntegration von Anwendungen. So kann die Autorisierung auch über externe Funktio-nen realisiert werden, wie z. B. durch die Verwendung eines bestehenden LDAP-Systems(Lightweight Directory Access Protocol). Umgekehrt kann in gleicher Weise dieses Modulfür externe Programme auch als ein zu integrierendes Modul angesehen werden, d. h. dritteProgramme könnten über eine Anwendungsintegration die Autorisierung der Mitarbeiterdurch das Berechtigungssystem des Produktkonfigurators durchführen lassen. Hiermit istjedoch ausdrücklich nicht gemeint, dass das Modul auch die Berechtigungsinformationenfür externe Anwendungen enthält, sondern lediglich eine Prüfung im Kontext des Pro-duktkonfigurators stattfindet.

Inferenzwerk

Das Modul Inferenzwerk ist für die Durchführung der Abhängigkeitsprüfungen verantwort-lich. Der Begriff der Inferenz ist dabei eine Ableitung des lateinischen Wortes infero undbedeutet sinngemäß „folgern“ und „schließen“. Das Modul wird des Öfteren auch als Regel-werk bezeichnet. Die unterschiedlichen Techniken zur Abhängigkeitsprüfung (siehe dazuAbschnitt 3.2.4.4) sind jedoch nicht allein auf regelbasierte Systeme beschränkt, weshalbin der vorliegenden Arbeit der etwas allgemeinere Begriff des Inferenzwerkes verwendetwird. Die Arbeitsweise des Moduls erfolgt wie beim Integrator auf eigenständige Art undWeise.


Aktivitätenprotokollierungssystem

Das Aktivitätenprotokollierungssystem ist ein weiteres eigenständig arbeitendes Modul. Eszeichnet alle Aktivitäten und Daten auf, die während der Interaktion zwischen dem Pro-duktkonfigurator und dem Benutzer generiert werden (siehe hierzu die Abbildung 4.7).Entsprechend der Datenart erfolgt die Speicherung in den Persistierungselementen Konfi-gurationsdaten und Verkehrsdaten. Basierend auf den so erfassten Informationen könnendurch die Einbindung weiterer Module, wie z. B. eines sogenannten Defaultwerks zur Gene-rierung von Empfehlungen, verkaufsfördernde und auf den Benutzer bezogene Aktivitätendurch den Produktkonfigurator initiiert werden.

Aktivitäten- und Datenfluss

Erf

ass

un

g

Aktivitäten-

protokollierungs-

system

Aktivität

Daten

Zeit

Abbildung 4.7: Arbeitsweise des Aktivitätenprotokollierungssystems

Datenaufbereitungssystem

Ein im Grundmodell als optional anzusehendes Modul ist das Datenaufbereitungssystem.Dieses ist nur im Rahmen einer dezentralen Architektur notwendig, da im Falle einer zen-tralen Architektur gemäß der Globalklassifikation (siehe dazu Abschnitt 3.2.4.3) keinerleiInformationen auf andere Systeme übertragen werden müssen. Die Datentransferierung istbei dem dezentralen Szenario hingegen eine Grundvoraussetzung, weshalb es der Funktio-nalität des Datenaufbereitungssystems bedarf. Hierbei sorgt das Modul für die Abfragealler für eine Replizierung erforderlichen Daten und bereitet diese gemäß der Anforderun-gen der Fat Clients auf. Diese Transformation ist notwendig, da nicht in jedem Fall dieDaten in dem vorliegenden Format auf den Fat Client transferiert werden können. Auch imUmkehrfall, d. h. wenn Daten der Fat Clients mit dem Zentralsystem synchronisiert werdenmüssen, erfolgt eine Bearbeitung der Informationen durch das Datenaufbereitungssystem.Das Modul stellt also, wie in der Abbildung 4.8 sichtbar, eine Art „Übersetzer“ und„Umwandler“ zur erfolgreichen Kommunikation und Datenverarbeitung zwischen den be-teiligten Systemen dar.

Datenverteilungssystem

Eine direkte funktionale Verbindung besteht zwischen dem letztgenannten Modul des Da-tenaufbereitungssystems und dem als Datenverteilungssystem bezeichneten Modul. Hinterdieser Bezeichnung stehen die Aufgaben der Replikation und Synchronisation. Nach derAufbereitung der Daten werden diese durch das Modul an die empfangsbereiten Sys-teme transferiert. Auch der Umkehrweg, die Synchronisation, wird durch dieses Modul


Daten-

aufbereitungs-

systemDB

z.B. XML

Abbildung 4.8: Funktionsprinzip des Datenaufbereitungssystems

umgesetzt. Zur erfolgreichen Konnektivität mit den verbundenen Systemen verfügt dasDatenverteilungssystem analog zum Integrator über ein intern gekoppeltes Persistierungs-element. Die Arbeitsweise des Moduls ist abhängig von den implementierten Replikations-und Synchronisationsverfahren. Eine theoretische Einführung in die Thematik dieser un-terschiedlichen Verfahren ist in [Lie03] zu finden.

4.3.2 Modulabhängigkeiten

Durch den modularen Aufbau des Grundmodells ergeben sich zwischen den unterschied-lichen Modulen eine Reihe von Zugriffsabhängigkeiten. Es werden also die von einem be-stimmten Modul ausgehenden Zugriffe auf andere Module beschrieben; eine Betrachtunghinsichtlich der Zugriffe auf die Persistierungselemente ist im Abschnitt 4.3.3 zu finden.Gemäß der folgenden Abbildung 4.9 werden bei der Betrachtung der Modulrelationenzwei Abhängigkeitsarten unterschieden. Mit intramediär werden Abhängigkeiten zwischenModulen bezeichnet, die sich innerhalb einer der drei im Grundmodell definierten Ebenenbefinden. Eine intermediäre Abhängigkeit besteht hingegen zwischen zwei Modulen, dieunterschiedlichen Ebenen zugeordnet sind.

Controller-Ebene View-Ebene

Modul

Modul

Modul

intramediäre Abhängigkeit

intermediäre Abhängigkeit

Abbildung 4.9: Veranschaulichung von Abhängigkeitsarten im Grundmodell

4.3.2.1 Interaktionswerk

Das der View-Ebene zugeordnete Interaktionswerk verfügt über jeweils eine intermediäreAbhängigkeit zu den Modulen Dialogwerk und Pflegesystem, die in der Abbildung 4.10


bildlich dargestellt sind. Der Zugriff des Interaktionswerkes erfolgt in gleicher Weise auf diezwei Module: Informationen, die aus der Entgegennahme von Benutzereingaben resultie-ren, werden an das Dialogwerk einerseits und an das Pflegesystem andererseits übermittelt.Im Folgenden seien zwei Beispiele zur besseren Verständlichkeit dieser Informationsüber-tragung genannt.

Abhängigkeit Interaktionswerk zu Dialogwerk Wenn ein Benutzer des Produkt-konfigurators in einem Konfigurationsprozess eine Produktkomponente selektiert, so er-folgt dies durch eine benutzerseitige Aktivität (z. B. ein Mausklick oder die Berührungdes Displays). Anhand dieser Aktivität erfasst das Interaktionswerk die Benutzereingabeund übermittelt ein Signal an das Dialogwerk mit den entsprechenden Informationen. DasDialogwerk empfängt diese und beginnt die Auswertung und Verarbeitung der Daten, wiesie bereits bei der Funktionsbeschreibung des Dialogwerkes erwähnt wurde.

Abhängigkeit Interaktionswerk zu Pflegesystem Auch bei der Interaktion einesMitarbeiters mit dem Produktkonfigurator kommt es zu gleichartigen benutzerseitigenAktivitäten; einzig der Kontext unterscheidet sich. So erfolgt auch hier durch das Interak-tionswerk eine Informationsübertragung an das Pflegesystem, welche Informationen, wiez. B. eine Produktbeschreibung oder ein bestimmter Preis für eine Produktkomponente,der Mitarbeiter über das Interaktionswerk an das Pflegesystem zur Persistierung übermit-telt hat.


werkDialogwerk

Abbildung 4.10: Abhängigkeiten des Moduls Interaktionswerk

4.3.2.2 Dialogwerk

Ähnlich dem Interaktionswerk verfügt auch das Dialogwerk, wie in Abbildung 4.11 dar-gestellt, über zwei Abhängigkeiten: eine intermediäre und eine intramediäre Abhängigkeit.Erstere existiert zum bereits betrachteten Interaktionswerk, Zweitere zum Inferenzwerk.Beide werden im Folgenden beschrieben.

Abhängigkeit Dialogwerk zu Interaktionswerk Das Dialogwerk hat wie bereits imAbschnitt 4.3.1.3 erwähnt die Aufgabe der Generierung von Texten für die Interaktionzwischen dem Produktkonfigurator und dem Benutzer. Derartige Texte müssen nach derErstellung in geeigneter Weise dem Benutzer sichtbar gemacht werden. Für diese Aufgabezeichnet sich das Interaktionswerk verantwortlich. Hieraus wird bereits die Notwendig-keit des vom Dialogwerk ausgehenden Zugriffs auf das Interaktionswerk deutlich: es wer-den die entsprechenden Inhalte übermittelt, sodass das Interaktionswerk diese darstellenkann. Durch den Zugriff des Dialogwerkes auf das Interaktionswerk existiert nunmehr einebeidseitige intermediäre Abhängigkeit.


Inferenzwerk

Interaktions-

werk

Dialogwerk

Abbildung 4.11: Abhängigkeiten des Moduls Dialogwerk

Abhängigkeit Dialogwerk zu Inferenzwerk Etwas komplexer gestaltet sich die in-tramediäre Abhängigkeit zwischen dem Dialogwerk einerseits und dem Inferenzwerk ande-rerseits. Die Grundlage für die Erstellung von Fehlermeldungen, Hinweisen und diversenanderen Texten findet sich u. a. auch im Ergebnis der Abhängigkeitsprüfung wieder. Somüssen z. B. dem Benutzer Hinweise darauf gegeben werden, ob eine Selektion einer be-stimmten Produktkomponente in einem konkreten Konfigurationsschritt möglich ist odernicht. Hierfür bedarf es der Übermittlung der in eine für das Inferenzwerk verständli-chen Sprache transformierten Benutzereingaben an das eben genannte Modul. So kannbasierend auf diesen Daten eine Ermittlung stattfinden, die zum Ergebnis hat, welche wei-teren Produktkomponenten ausgewählt werden können und welche fortan nicht mehr zurVerfügung stehen.

4.3.2.3 Pflegesystem

Das Pflegesystem, als ein nicht eigenständig arbeitendes Modul, bedarf der Interaktionmit einem Benutzer. Aus diesem Grund verfügt es über eine intermediäre Abhängigkeitzum Modul Interaktionswerk. Darüber hinaus gibt zwei intramediäre Abhängigkeiten zuden Modulen Berechtigungssystem und Inferenzwerk, die allesamt auch in der folgendenAbbildung 4.12 dargestellt sind.

Abhängigkeit Pflegesystem zu Interaktionswerk Die intermediäre Abhängigkeitzwischen dem Pflegesystem und dem Interaktionswerk ähnelt der gleichartigen Abhängig-keit zwischen dem Dialog- und dem Interaktionswerk. Auch hier übermittelt das Pflege-system die entsprechenden Informationen, wie z. B. die zurzeit gültigen Wertbelegungenfür Produktkomponenten oder aber die aktuellen Produktbeschreibungen, zum Interakti-onswerk, damit durch dieses die Daten für den Benutzer visualisiert werden können.

Abhängigkeit Pflegesystem zu Berechtigungssystem Die Benutzung des Pflege-systems ist nur dafür vorgesehenen Mitarbeitern gestattet, sodass ein Zugriff des Pflegesys-tems auf das Modul Berechtigungssystem erforderlich ist. Versucht z. B. ein Mitarbeiter einProdukt in seiner Zusammensetzung anzupassen, so hat dieser im Vorlauf seine Kenndatenzur Autorisierung einzugeben. Das Pflegesystem greift dann auf eine Abfragefunktion desBerechtigungssystems zu und abhängig vom Ergebnis der Prüfung werden dem Mitarbeiterdie entsprechenden Rechte zur Ausführung der Aktionen erteilt.


Inferenzwerk


werk

Berechtigungs-

system

Abbildung 4.12: Abhängigkeiten des Moduls Pflegesystem

Abhängigkeit Pflegesystem zu Inferenzwerk Eine besondere Art der Abhängigkeitexistiert zwischen dem Pflegesystem und dem Inferenzwerk. Diese Art wird in dieser Arbeitauch als beidseitige Implementierungsabhängigkeit bezeichnet. Abhängig von der genauenTechnik, die im Inferenzwerk eingesetzt wird, gestaltet sich die technische Implementie-rung des Pflegesystems. Da durch dieses die jeweiligen Abhängigkeitsbeschreibungen derProduktkomponenten modifiziert werden können, muss es die Logik des Inferenzwerkesverstehen und nachvollziehen können. Zudem ist auch während der Modifizierung derarti-ger Daten eine laufzeitbezogene Prüfung erforderlich, sodass durch die Mitarbeiter keineProduktkomponenten zusammengestellt werden können, deren Kombinationen im Prozessder Konfiguration dann zu Widersprüchen führen.

4.3.2.4 Aktivitätenprotokollierungssystem

Das Modul Aktivitätenprotokollierungssystem verfügt nur über eine intramediäre Abhän-gigkeit zum Modul Dialogwerk. Dahinter verbirgt sich die bereits bei der Modulbeschrei-bung und in der Abbildung 4.7 dargestellte Funktionalität der Daten- und Aktivitäts-erfassung. So hat das Aktivitätenprotokollierungssystem Zugriff auf das Dialogwerk undkann dadurch alle relevanten Informationen, wie z. B. das konkrete Auswahlverhalten desBenutzers, erfassen und für eine spätere Auswertung in die entsprechenden Persistierungs-elemente ablegen.

4.3.2.5 Inferenzwerk

Neben der beidseitigen Implementierungsabhängigkeit, die bereits beim Pflegesystem be-schrieben wurde, verfügt das Modul über eine intramediäre Abhängigkeit zum Modul Dia-logwerk. Basierend auf den vom Dialogwerk transferierten Daten (siehe Abschnitt 4.3.2.2)wird ermittelt, welche Produktkomponenten im nächsten Konfigurationsschritt als ver-fügbar gelten. Das Ergebnis dieser Prüfung wird dann durch das Inferenzwerk an dasDialogwerk übertragen, worin die Abhängigkeit ihre Begründung erfährt.


4.3.2.6 Steuerung

Die Abhängigkeiten des Steuerungsmoduls sind vielfältiger Natur. Zu jedem im Grund-modell enthaltenen Modul hat die Steuerung eine intra- bzw. intermediäre Abhängigkeitvorzuweisen. Die Ursache hierfür liegt in der globalen Aufgabenstruktur des Moduls. Auf-grund der Gewährleistung der Aktualisierungsmöglichkeiten der Module oder aber derEigenschaft der integrativen Erweiterbarkeit im Sinne des Hinzufügens und des Entfer-nens von externen Modulen bedarf es jederzeit einer Zugriffsmöglichkeit der Steuerungauf die im Grundmodell existierenden Module.

4.3.2.7 Datenaufbereitungs- und Datenverteilungssystem

Zwischen den beiden als optional betrachteten Modulen Datenaufbereitungs- und Daten-verteilungssystem existieren untereinander eine direkte intramediäre Abhängigkeit. Die-se ist dadurch gegeben, dass nach der Transformation der eingesammelten Daten durchdas Datenaufbereitungssystem diese an das Datenverteilungssystem weitergeleitet wer-den müssen, damit sie letztlich an die angekoppelten Fat Clients übertragen werden kön-nen. Im Falle der Umkehrrichtung, also der Synchronisation ausgehend von den Fat Cli-ents auf das Zentralsystem, erfolgt eine Übermittlung der empfangenen Daten über dasDatenverteilungs- an das Datenaufbereitungssystem zur fehlerfreien Verteilung auf die imGrundmodell enthaltenen Persistierungselemente.

4.3.3 Datenzugriffe und Persistierung

Bislang erfolgte die Betrachtung des integrativen Grundmodells im Zusammenhang mitden Abhängigkeiten der Module untereinander. In diesem Abschnitt soll nun der Fokus aufden Datenzugriffen und der Persistierung der Informationen im integrativen Grundmodellliegen. Hierzu sei auf die Abbildung 4.13 hingewiesen, die das Grundmodell und einzigdie Datenzugriffe der Module auf die jeweiligen Persistierungselemente enthält.Grundsätzlich werden in dieser Betrachtung zwei Arten unterschieden: lesende und schrei-bende Datenzugriffe. Mit Blick auf die Persistierungselemente gilt die Unterteilung nachder datensemantischen Klassifikation, die bereits im Abschnitt 3.3 vorgestellt wurde.

4.3.3.1 Lesende Zugriffe

Die Zugriffsmöglichkeiten der Module auf die jeweiligen Persistierungselemente sind ent-sprechend der Funktionalitäten der Module reglementiert. So hat beispielsweise das Inter-aktionswerk nur Zugriff auf die Oberflächendaten im gleichnamigen Persistierungselement,um die notwendigen Informationen, wie z. B. die Style-Definitionen, für die Darstellung derInhalte abzufragen. Es handelt sich hierbei um einen Lesezugriff, da das Interaktionswerkals solches keinerlei Oberflächendaten modifiziert und damit keine Schreibrechte benötigt.Weitere Beispiele für ausschließliche Lesezugriffe finden sich bei dem Dialogwerk und demInferenzwerk wieder. Bei Ersterem ist die Abfrage von Daten aus den Persistierungselemen-ten Oberflächendaten und Modelldaten gestattet. Basierend auf das bereits vorgestellteAufgabenspektrum des Moduls lässt sich ableiten, dass auch hier keinerlei Aktivität zurModifizierung von Informationen vorgesehen ist. Das Dialogwerk fragt stattdessen sämt-liche Modelldaten und relevante Oberflächendaten ab, um die entsprechenden Texte und


Inferenzwerk

Pflegesystem

Integrator C

Interaktions-

werk

Dialogwerk

SteuerungBerechtigungs-

system

Aktivitäten-

protokollierungs-

system

Datenaufbe-

reitungssystem

Oberflächendaten

Modelldaten

Administra-

tionsdaten

Konfigurations-

daten

Integrator B

Mitarbeiter-

stammdaten

Datenver-

teilungssystem

Produkt-

informationssysteme

Integrator A

Kunden-

informationssysteme

Verkehrsdaten

externe Daten Lese- und SchreibzugriffLesezugriff

Model-Ebene

(interne Daten)

Module der

Controller-Ebene

Module der

View-Ebeneoptional; nur bei dezentraler Architektur

Abbildung 4.13: Datenzugriffe der Module auf die Persistierungselemente im integrativenGrundmodell

Hinweise zu generieren. Analog verhält es sich bei dem Modul Inferenzwerk: Es erfolgteinzig die Abfrage der für die Abhängigkeitsprüfung notwendigen Informationen aus demPersistierungselement Modelldaten.


4.3.3.2 Schreibende Zugriffe

Der weit größere Teil der Zugriffe auf die Persistierungselemente erfolgt in Form von kom-binierten Lese- und Schreibzugriffen. So erhalten die Module Integrator, Pflegesystem,Datenaufbereitungssystem, Steuerung, Aktivitätenprotokollierungssystem und Berechti-gungssystem die jeweiligen Zugriffsrechte auf die Persistierungselemente innerhalb der ent-sprechenden Sinneinheit. Ein Beispiel für eine derartige Sinneinheit ist der Zugriff des Ak-tivitätenprotokollierungssystems auf die Verkehrs- und Konfigurationsdaten. Gemäß derAufgabenformulierung erfasst dieses alle relevanten Daten und Aktivitäten, die bei derInteraktion zwischen dem Produktkonfigurator und dem Benutzer generiert werden (siehehierzu Abschnitt 4.3.1.3), sodass es für die erforderliche Persistierung einen Schreibzugriffauf die genannten Speichereinheiten benötigt.

4.4 Modellvalidierung

Der vierte Schritt im Prozess der Modellbildung (siehe hierzu Abschnitt 4.2) beinhaltetdie Validierung des Modells. Im Rahmen dieser Arbeit erfolgt sie in zweierlei Form: zumeinen als Anwendungs- und zum anderen als Anforderungsvalidierung. Erstere betrachtetAktivitäten eines Kunden und eines Mitarbeiters und zeigt die funktionalen Vorgänge desGrundmodells anhand der jeweiligen Aktivität auf. Natürlich stellt diese Art der Funk-tionsbeschreibung und der Vorgangssimulation nur eine Betrachtung der angewandtenTheorie dar und entspricht keiner praktischen Modellvalidierung. Einen derartigen prak-tisch fundierten Beweis der Funktionsfähigkeit eines Produktkonfigurators, welcher basie-rend auf dem vorliegenden Grundmodell implementiert wird, ist im Rahmen dieser Arbeitnicht vorgesehen, weshalb sich die Validierung an dieser Stelle auf diese abstrakte Sichtwei-se beschränkt. Die Anforderungsvalidierung gibt Auskunft über die Zuständigkeitsbereicheder Module in Hinblick auf die im Abschnitt 2.2.4 aufgestellten Anforderungen an Pro-duktkonfiguratoren.

4.4.1 Anwendungsvalidierung

Im Rahmen der Anwendungsvalidierung des Grundmodells sollen die folgenden zwei Sze-narien betrachtet werden:

1. Ein beliebiger Kunde stellt ein beliebiges Produkt zusammen.

2. Ein beliebiger Mitarbeiter ändert die Zusammenstellung eines beliebigen Produktes.

Beide Szenarien unterliegen der Annahme einer Online-Systeminteraktion des Produkt-konfigurators und werden in den folgenden zwei Unterabschnitten detailliert betrachtet.Hierzu werden die Schritte des Kunden bzw. Mitarbeiters kursiv dargestellt und die dazu-gehörige Erklärung der Arbeitsweise des Grundmodells im darunter folgenden Abschnittjeweils genannt.

4.4. MODELLVALIDIERUNG 79

4.4.1.1 Szenario 1: Produktzusammenstellung durch Kunden

Schritt 1: Der Kunde ruft die grafische Oberfläche des Produktkonfigurators über seinenClient (z. B. einen Browser) auf. (Der Konfigurationsprozess ist hierbei noch nicht ge-startet.)

Erklärung: Das Interaktionswerk erfasst die für die Anzeige der grafischen Oberfläche re-levanten Informationen aus dem gleichnamigen Persistierungselement und bereitet diesegemäß der Anforderungen des Clients auf. Das Dialogwerk bedient sich ebenfalls aus denOberflächendaten und übermittelt u. a. die kundenbezogenen Hinweise zur Nutzung desProduktkonfigurators an das Interaktionswerk. Es erfolgt nun ausgehend vom letztgenann-ten Modul die Anzeige der grafischen Oberfläche inklusive der für den Kunden relevantenHinweise.

Schritt 2: Der Kunde startet den Konfigurationsprozess mit einem Klick auf das dafürvorgesehene Interaktionselement.

Erklärung: Das Interaktionswerk erkennt die kundenseitige Aktivität durch die Betätigungdes Interaktionselementes. Durch die Erfassung kann das Interaktionswerk die entspre-chende Transformation in ein Signal vornehmen, welches an das Dialogwerk weitergeleitetwird. Dieses fungiert fortan als Vermittler. Das Dialogwerk informiert das Inferenzwerkund fragt die möglichen Produktkomponenten ab, die zur Auswahl angezeigt werden kön-nen. Hierfür bedient sich das Inferenzwerk aus dem Persistierungselement Modelldatenund wertet die vorliegenden Informationen aus. Als Ergebnis der Auswertung übermit-telt das Inferenzwerk dem Dialogwerk die konkreten Produktkomponenten. Das Dialog-werk bereitet diese Daten auf, indem es zu den konkreten Produktkomponenten weitereInformationen über das Persistierungselement Modelldaten einholt. Damit angereichertwerden die Informationen an das Interaktionswerk zurückgegeben, sodass der Kunde nuneine Übersicht vorfindet, die es ihm ermöglicht, mit der Konfiguration des Produktes zubeginnen. Natürlich erfolgt auch hier wieder der Zugriff ausgehend vom Dialog- und In-teraktionswerk auf die Oberflächendaten. Während des gesamten Vorgangs ist auch dasAktivitätenprotokollierungssystem aktiv. So erfasst dieses beispielsweise, mit welchen Pro-duktkomponenten der Kunde die Konfiguration begonnen hat und welche Verkehrsdatenüberhaupt zwischen dem Kunden und dem Produktkonfigurator über das Dialogwerk aus-getauscht werden.

Schritt 3: Der Kunde selektiert eine Produktkomponente und geht in den nächsten Schrittder Konfiguration über.

Erklärung: Auch in diesem Schritt erfolgt die Entgegennahme der Kundenaktivität durchdas Interaktionswerk. Es erkennt, dass der Kunde eine der angebotenen Produktkompo-nenten ausgewählt hat. Diese Information wird in der Folge an das Dialogwerk übermit-telt, welches wiederum eine Anfrage an das Inferenzwerk sendet, um die Konsequenzenaus der Auswahl zu ermitteln. Das Inferenzwerk prüft anhand der in den Modelldatenabgelegten Abhängigkeitsbeschreibungen, welche Produktkomponenten nach der erfolg-ten Selektion auch weiterhin verfügbar sind. Über das Ergebnis dieser Prüfung informiertdas Inferenzwerk das Dialogwerk, welches diese Daten mit der bereits erwähnten Infor-mationsanreicherung an das Interaktionswerk übermittelt, sodass der Kunde die weiterenKonfigurationsschritte vollziehen kann. Außerdem erfolgt bei der Interaktion des Dialog-werkes mit dem Inferenzwerk eine Erfassung des Fortschritts der Konfiguration durch dasAktivitätenprotokollierungssystem, sodass auch im Falle einer Fehlentscheidung durch den


Kunden die Auswahl einer Produktkomponente rückgängig gemacht werden könnte. Dergesamte soeben beschriebene Vorgang wiederholt sich solange, bis das Produkt fertig zu-sammengestellt ist.Schritt 4: Der Kunde hat das Produkt konfiguriert und will z. B. die Konfiguration abspei-chern.Erklärung: Das Dialogwerk erfährt in gewohnter Weise über das Interaktionswerk, dass derKunde die Konfiguration abgeschlossen hat und nun die erstellte Konfiguration mit einerentsprechenden Bezeichnung speichern möchte. Diese Information bereitet das Dialogwerkderart auf, dass das Aktivitätenprotokollierungssystem eine Art Kommando erkennt, wel-ches ihm die Aufgabe der Ablegung der endgültigen Konfigurationsdaten in dem Persis-tierungselement Konfigurationsdaten zuteilt. Dieser Aufgabe kommt das Modul nach; dieKonfiguration als solche wird erfolgreich persistiert.Einen Überblick über die für dieses Szenario relevanten Module liefert dieAbbildung 4.14,in der zudem die für den zentralen Schritt 3 relevanten Aktivitäten innerhalb des Modellssichtbar und entsprechend der Legende mit einer Kurzbeschreibung versehen sind.

Konfigurator-

system

Inferenzwerk

Interaktions-

werk

Dialogwerk

Aktivitäten-

protokollierungs-

system

Oberflächendaten

Modelldaten

9b

6

4b

23, 8

11

14

Konfigurations-

daten

Verkehrsdaten

4a, 9a

1

5

7

10

12

13

16

15

Legende:

1 Selektion der Produktkomponente

2 Signalübermittlung

3 Erfassung durch das Aktivitätenproto-

kollierungssystems

4a Persistierung der erfassten Daten

4b Übermittlung der Selektionsinformationen

5 Abfrage der Abhängigkeitsbeschreibungen

6 Übermittlung des Abfrageergebnisses

7 Übermittlung des Prüfergebnisses

8 Erfassung durch das Aktivitätenproto-

kollierungssystems

9a Persistierung der erfassten Daten

9b Abfrage der Produktinformationen


11 Abfrage relevanter Oberflächendaten


13 Übertragung der aufbereiteten Daten

14 Abfrage der für die Anzeige relevanten Daten


16 Darstellung der nun noch zur Auswahl

stehenden Produktkomponenten

Kunde

Abbildung 4.14: Schema des dritten Schrittes des Szenarios 1

4.4.1.2 Szenario 2: Produktdatenänderung durch Mitarbeiter

Schritt 1: Der Mitarbeiter ruft die Verwaltungsoberfläche des Produktkonfigurators auf.Erklärung: Wie bereits im ersten Szenario unter Schritt 1 erklärt, erfolgt auch in diesemFall die Zusammenstellung der Oberflächendaten durch das Interaktionswerk, sodass der


Client diese entsprechend darstellen kann. Zudem erfolgt die Initialisierung des ModulsPflegesystem, sodass der Mitarbeiter auf die in diesem Modul implementierte Funktions-weise Zugriff erhält. Der Mitarbeiter sieht als Ergebnis dieses Vorgangs ein Formular zurEingabe der Zugangsdaten.

Schritt 2: Der Mitarbeiter gibt die Zugangsdaten zur Nutzung des Konfiguratorsystems ein.

Erklärung: Das Interaktionswerk erfasst in gewohnter Weise die benutzerseitige Eingabeder Kenndaten und leitet diese an das Pflegesystem weiter. Dieses prüft die Korrektheitdes eingegebenen Benutzernamens und Passwortes, indem es eine Abfrage an das ModulBerechtigungssystem stellt. Letztgenanntes vergleicht dann die übermittelten Daten mitdenen im Persistierungselement Administrationsdaten vorliegenden Kennungen und gibtein Prüfergebnis an das Pflegesystem zurück. Fällt das Prüfergebnis positiv aus, so giltder Mitarbeiter als im System angemeldet und hat nun z. B. die Möglichkeit, eine Über-sichtsseite anzusehen. Fällt das Prüfergebnis hingegen negativ aus, so erfolgt die Anzeigeeiner Fehlermeldung bzw. eines Hinweistextes, dass die eingegebenen Kenndaten falschsind. Dieser Vorgang wiederholt sich solange, bis der Mitarbeiter die richtigen Kennda-ten eingibt, er von weiteren Versuchen absieht oder das System keine weiteren Versuchemehr zulässt. Für die textuelle Gestaltung der Hinweise und Fehlermeldungen greift dasPflegesystem fortlaufend auf das Persistierungselement Oberflächendaten zu.

Schritt 3: Der Mitarbeiter selektiert ein Produkt zur Bearbeitung dessen Eigenschaften.

Erklärung: Der Mitarbeiter hat z. B. auf der in der Erklärung zu Schritt 2 erwähntenÜbersichtsseite, welche ihm bereits nach dem erfolgreichen Anmelden dargestellt wird,die Möglichkeit, Produkte zur Bearbeitung auszuwählen. Nach dem konkreten Vorgangder Produktselektion übermittelt das Interaktionswerk die entsprechende Produktiden-tifikationsnummer an das Pflegesystem, das für die Bereitstellung der zu bearbeitendenEigenschaften sorgt. Hierfür erfolgt ein Zugriff auf das Persistierungselement Modellda-ten. Die entsprechenden Daten werden an das Interaktionswerk zur Darstellung im Clientweitergeleitet.

Schritt 4: Der Mitarbeiter ändert eine Abhängigkeitsbeschreibung zwischen zwei Kompo-nenten des selektierten Produktes.

Erklärung: Auch in diesem Fall erfolgt die Erfassung der benutzerseitigen Aktivitätendurch das Interaktionswerk. Dieses leitet die Änderungswünsche des Mitarbeiters an dasPflegesystem in aufbereiteter Form weiter, wodurch dann ausgehend von diesem eine An-frage an das Inferenzwerk erfolgt. Diese Anfrage ist notwendig, damit überprüft werdenkann, ob die neue Beschreibung nicht gegen bereits bestehende Abhängigkeiten verstößtoder es zu unerwünschten Nebeneffekten kommt. Damit eine derartige Überprüfung durch-geführt werden kann, muss das Inferenzwerk auf das Persistierungselement Modelldatenzugreifen. Nach erfolgreicher Prüfung wird die geänderte Abhängigkeitsbeschreibung angewohnter Stelle persistiert und der Mitarbeiter via Interaktionswerk über den erfolgrei-chen Änderungsfortschritt informiert. Im Falle eines negativen Prüfergebnisses erhält derMitarbeiter ausgehend vom Pflegesystem über das Interaktionswerk einen Hinweis auf diedurch die Änderung hervorgerufenen Probleme.

Eine schematische Darstellung der Funktionsweise aller beteiligten Module des integrativenGrundmodells in Bezug auf den beschriebenen vierten Schritt des zweiten Szenarios zeigtdie folgende Abbildung 4.15.


Konfigurator-

system

Inferenzwerk

Pflegesystem

Interaktions-

werk

Oberflächendaten

7

Modelldaten

4 3

2

8

1

5

6

9

10

1112

13

Legende:

1 Erfassung der Änderungswünsche

2 Weiterleitung der aufbereiteten Daten

3 Prüfanfrage an das Inferenzwerk auf Korrektheit

4 Anforderung der notwendigen Abhängigkeits-

beschreibungen

5 Übermittlung der geforderten Daten

6 Übermittlung des Prüfergebnisses

7 Persistierung bei erfolgreichem Prüfergebnis

8 Anforderung von Oberflächendaten

9 Übermittlung der angeforderten Daten

10 Übermittlung des Hinweistextes nach Abschluss

des Änderungsvorgangs

11 Anforderung von Oberflächendaten

12 Übermittlung der angeforderten Daten

13 Darstellung des Ergebnisses des Änderungsvorgangs

Mitarbeiter

Abbildung 4.15: Schema des vierten Schrittes des Szenarios 2

4.4.2 Anforderungsvalidierung

Der zweite Bestandteil der Modellvalidierung legt dar, welche Anforderungen durch wel-che Module des integrativen Grundmodells erfüllt werden. Diese Zuordnung soll zudemdie Möglichkeiten des Grundmodells in Bezug auf eine Implementierung und damit eineAbbildung der Theorie in die Praxis aufzeigen. Hierzu wird für die Betrachtung die ausAbschnitt 2.2.4 bekannte Differenzierung in kundenseitige und anbieterseitige Anforderun-gen an Produktkonfiguratoren aufgegriffen. Für eine Gesamtübersicht der Anforderungensei auf die Abbildung 2.12 verwiesen. An dieser Stelle wird zudem darauf aufmerksamgemacht, dass die Module Datenaufbereitungs- und Datenverteilungssystem in diesem Ab-schnitt keine Betrachtung finden, da diese lediglich dafür sorgen, dass bereits bestehendeDaten repliziert und synchronisiert werden.

Eine Übersicht über die Anforderungen aus Kunden- und Anbietersicht sowie der Zuord-nung der Verantwortlichkeiten in Bezug auf die Module des integrativen Grundmodellsfindet sich in der folgenden Tabelle 4.2.

Keine direkte Zuordnung ist in den beiden Anforderungssichten für das Modul des Berech-tigungssystems zu verzeichnen. Dieser Umstand ist darin begründet, dass es zwar primärkeinerlei Anforderungspunkte in direkter Weise berührt, es aber indirekt für die Gewähr-leistung eines sicheren Systems zuständig ist. Hiermit ist vordergründig die Zusicherunggemeint, dass ein Benutzer des Systems für die Ausführung der entsprechenden Aktivitäteneine Autorisierung erhalten muss.


Anforderung/ Modul Pfl

egesystem

Interaktionswe

rk

Dialogw

erk

Steu

erun

g

Integrator

Berechtig

ungssystem

Inferenz

werk

Aktivitä

tenp

rotokol-

lierung

ssystem

Kundenseitige AnforderungenHohe Benutzerfreundlichkeit × ✓ ✓ × × × × ✓

Vollständiges Informationssystem × ✓ ✓ × ✓ × × ×

Sitzungspersistenz × × × × ✓ × × ✓

Gültige und konsistente Problemlösung ✓ × ✓ × × × ✓ ✓

Konfigurationsflexibilität × × ✓ × × × ✓ ✓

Niedrige Latenz × ✓ ✓ ✓ × × ✓ ×

Anbieterseitige AnforderungenMächtige Konfigurationssprache ✓ × × × × × ✓ ×

Plausibilitätsprüfung ✓ × × × × × ✓ ×

Flexibilität des Konfigurationswissens ✓ × × × × × ✓ ×

Systemintegration und Kompatibilität × × × ✓ ✓ × × ×

Wartbarkeit × × × ✓ × × × ×

Ausfallsicherheit × × × ✓ × × × ×

Kundenpflege × × × × ✓ × × ✓

Vertriebsunterstützung × × × × ✓ × × ✓

Analysefähigkeit × × × × ✓ × × ✓

Legende:✓: zuständig | ×: nicht zuständig

Tabelle 4.2: Kunden- und anbieterseitige Anforderungsvalidierung

4.4.2.1 Anforderungen aus Kundensicht

In der Gesamtbetrachtung der kundenseitigen Anforderungen ist das Steuerungsmodul zunennen, da es u. a. für die Lauffähigkeit des Gesamtsystems verantwortlich ist und somitalle weiteren Anforderungen indirekt berührt.

In Bezug auf eine hohe Benutzerfreundlichkeit zeichnen sich im Wesentlichen drei Moduledes Grundmodells verantwortlich: das Interaktions- und Dialogwerk sowie das Aktivitäten-protokollierungssystem. Ersteres ist für die kompatible Ansicht des Produktkonfiguratorsauf den verschiedenen zur Auswahl stehenden Clients verantwortlich, die in unterschiedli-cher Art und Weise die vielfältigen Style-Definitionen interpretieren. Auch das Dialogwerkträgt mit der Generierung der Texte wesentlich zur Benutzerfreundlichkeit bei, da dieQualität der Inhalte, die über das Interaktionswerk an den Kunden übermittelt werden,diesen überzeugen und unterstützen müssen, sodass der Produktkonfigurator letztlich alsverkaufsförderndes Instrument dient. Auch mit Blick auf eine internationalisierte Informa-


tionsdarstellung tragen beide Module durch die korrekte Auswahl der Oberflächendatenzur Erzielung einer hohen Benutzerfreundlichkeit maßgeblich bei. Bei der Erweiterung desModells, beispielsweise durch ein Defaultwerk, welches für die Generierung von Empfeh-lungen zuständig ist, versorgt das Aktivitätenprotokollierungssystem das Defaultwerk mitInformationen, wie z. B. über das Verhalten des Kunden. Aus diesem Grund trägt es auchzu einer hohen Benutzerfreundlichkeit bei.Für die Gewährleistung einer vollständigen Informationsdarstellung der Produktdaten sindwie bereits im vorherigen Anforderungspunkt das Interaktionswerk und das Dialogwerkverantwortlich. Aber auch der Integrator nimmt hier eine wichtige Rolle ein, da er für dieIntegration von Informationen zuständig ist und so das System des Produktkonfiguratorsum relevantes Wissen erweitert.Die Möglichkeit der Speicherung einer Konfiguration fällt unter den Anforderungspunktder Sitzungspersistenz, welcher vordergründig durch das Aktivitätenprotokollierungssys-tem erfüllt wird. Dieses erfasst nicht nur sämtliche Informationen, die zwischen dem Kun-den und dem Produktkonfigurator transferiert werden, sondern persistiert auch die Kon-figurationsdaten. In diesem Zusammenhang steht auch das Modul Integrator A, welchesfür die Integration und Verteilung derartiger Konfigurationsdaten zuständig ist.Die gültige und konsistente Problemlösung berührt mehrere Module des Grundmodells.Neben dem Interaktionswerk, welches wie auch in den vorherigen Fällen vor allem derzuverlässigen Kommunikation des Systems mit dem Kunden dient, übernehmen auch dasDialogwerk, das Inferenzwerk und das Aktivitätenprotokollierungssystem wichtige Aufga-ben. Entscheidend ist hierbei die Zusammenarbeit der drei Module: Das Dialogwerk sorgtfür die textuelle Begleitung des Vorgangs der Problemlösung, das Inferenzwerk nimmtdie Prüfung und Mitteilung der Kombinationsmöglichkeiten der Produktkomponenten vorund das Aktivitätenprotokollierungssystem gewährleistet u. a. die Zwischenspeicherungder jeweiligen Konfigurationsschritte, sodass während der Problemlösung auch auf frühereSchritte zurückgegriffen werden kann. Die drei letztgenannten Module ermöglichen somitauch die geforderte Konfigurationsflexibilität im Sinne des Zurücksetzens von getroffenenEntscheidungen.Der sechste Anforderungspunkt, eine niedrige Latenz, betrifft vier Module des integra-tiven Grundmodells. So ist die Arbeitsweise des Interaktionswerkes entscheidend für dieGröße der Latenz. Hiermit ist u. a. die Zeit gemeint, die es benötigt, um die benutzerseiti-gen Aktivitäten zu empfangen und zu verarbeiten. Der Bezug zur Größe der Latenz trifftauch auf die Module Steuerung, Dialogwerk und Inferenzwerk zu. Vor allem bei Letzte-rem entscheidet die Komplexität der gewählten Konfigurationssprache und der Technikzur Abhängigkeitsprüfung über die Arbeitsweise des Moduls und der davon abhängigenLatenz.

4.4.2.2 Anforderungen aus Anbietersicht

Die Konfigurationssprache findet sich in implementierter Form im Modul Inferenzwerk wie-der, weshalb es sich für die Erfüllung dieses Anforderungspunktes verantwortlich zeigt. Da-mit in direkter Verbindung steht auch das Pflegesystem (siehe dazu auch Abschnitt 4.3.1.3),welches sich mit dem Inferenzwerk in einer beidseitigen Implementierungsabhängigkeit be-findet. Um also der Anforderung einer mächtigen Konfigurationssprache und einer gutenPerformance bei der Auswertung der Abhängigkeitsbeschreibungen gerecht zu werden,

4.5. SYNERGIEEFFEKTE 85

bedarf es auch der optimalen Funktionsweise der beiden Module. Ebenso zeichnen sichdas Inferenzwerk und das Pflegesystem für die Anforderungen Plausibilitätsprüfung undFlexibilität des Konfigurationswissens verantwortlich.Zwei andere Module des integrativen Grundmodells stehen bei der vierten Anforderung,der Systemintegration und Kompatibilität, im Fokus. Hierbei sorgt der Integrator für dieEinspeisung und Verteilung von Informationen zwischen dem Produktkonfigurator undden entsprechenden Systemanwendungen. In Bezug auf die Kompatibilität der Systemeuntereinander sorgt das Steuerungsmodul für die Bereitstellung der Kompatibilitätsinfor-mationen und Verwaltung aller beteiligten Module des Grundmodells.Auch für die Wartbarkeit und die Ausfallsicherheit spielt die Steuerung eine zentrale Rolle,da über dieses Modul entsprechende Aktualisierungen im Gesamtsystem verzeichnet undvorgenommen werden können. Darüber hinaus führt das Steuerungsmodul ein Systempro-tokoll, welches Unregelmäßigkeiten im Betriebsablauf registriert und persistiert. An dieserStelle sei jedoch darauf hingewiesen, dass der Anforderungspunkt der Ausfallsicherheit imWesentlichen von der Systemarchitektur abhängig ist, auf dem der Produktkonfiguratorbzw. das gesamte System ausgeführt werden. Auch die gewährleistete Hochverfügbarkeits-klasse hat eine hohe Aussagekraft über die Ausfallsicherheit des Systems. EinführendeInformationen zu dieser Thematik sind unter [Kru09] nachzulesen.Die Anforderungspunkte der Kundenpflege, der Vertriebsunterstützung und der Analyse-fähigkeit fallen gleichermaßen in die Zuständigkeitsbereiche der Module Integrator undAktivitätenprotokollierungssystem. Der Integrator dient als Brücke zwischen den unter-nehmensseitigen Anwendungssystemen und dem Produktkonfigurator und gewährleistetso eine angepasste Kundenpflege. Zudem sorgt er für eine verbesserte Vertriebsunterstüt-zung durch die Nutzung aller Daten und die Möglichkeit zur Auswertung der Verkehrs-und Konfigurationsdaten, die auch durch den Integrator auf angekoppelte Systeme verteiltoder von diesen eingeholt werden können. Daneben sorgt auch das Aktivitätenprotokol-lierungssystem durch die bereits beschriebene Datenerfassung für die Erfüllung der dreiAnforderungen.

4.5 Synergieeffekte

Durch den integrativen Charakter des Grundmodells und der daraus entstehenden Sym-biose von Anwendungen eines Unternehmens auf der einen und einem Produktkonfiguratorauf der anderen Seite bilden sich basierend auf der beidseitigen Integration von Daten undAnwendungen eine Reihe von Synergieeffekten heraus, von denen ausgewählte im Folgen-den betrachtet werden. Derartige Effekte sind dabei als Ergänzung für die Nutzenpunkteanzusehen, die bereits im Abschnitt 2.2.4.3 genannt wurden.

4.5.1 Produktbezogene Erkenntnisgewinnung

Während des Vorgangs der Produktzusammenstellung durch einen Kunden entstehen eineVielzahl von Informationen, die eine hohe Aussagekraft über die Produktkomponenten imEinzelnen wie auch die Produkte im Ganzen besitzen. Ein Beispiel hierfür ist die Statistiküber ausgewählte Produktkomponenten. So lassen Produktbestandteile, die viel häufigerals andere in der Konfiguration selektiert werden, vermuten, dass sie auf den Kunden


bezogen u. a. eine höhere Attraktivität vorzuweisen haben. Gleiches gilt im Umkehrfall:Produktbestandteile, deren Selektivitätshäufigkeit an unterer Stelle rangieren, müssen inirgendeiner Art und Weise Merkmale aufweisen, die einer Entscheidung für diese Kom-ponente entgegenwirken. Als Beispiele für solche Merkmale seien ein zu hoher Preis oderdie unvorteilhafte Anordnung der Produktkomponenten innerhalb des Konfiguratorsys-tems zu nennen. Derartige Erkenntnisse sind für das anbietende Unternehmen von hoherBedeutung, da es so auf das Verhalten der Konsumenten reagieren kann. Im Rahmen desintegrativen Grundmodells werden diese Daten durch das Aktivitätenprotokollierungssys-tem erfasst und in die entsprechenden Persistierungselemente abgelegt. Durch die Verar-beitung dieses Wissens mit den Fakten, die bereits in den Produktinformationssystemenenthalten sind, können neuartige Erkenntnisse gewonnen werden, die letztlich wieder indie Modelldaten eingearbeitet werden können. Die folgende Abbildung 4.16 zeigt diesenWirkungskreislauf im Bezug auf das integrative Grundmodell.

Integrator C

Aktivitäten-

protokollierungs-

system

ModelldatenKonfigurations-

daten

Produkt-

informationssysteme

Integrator A

Kunden-

informationssysteme

Verkehrsdaten

Daten-

auswertung

Datenextraktion

Daten

extra

ktio

n

Erk

enn

tnisin

tegra

tion

Abbildung 4.16: Produktbezogene Erkenntnisgewinnung

4.5.2 Kundenbezogene Erkenntnisgewinnung

In gleicher Weise von hoher Bedeutung für die kundenbezogene Erkenntnisgewinnung sinddie Interaktionsdaten, die beim Konfigurationsprozess zwischen dem Kunden und demProduktkonfigurator transferiert werden.Wie bereits bei der Funktionsbeschreibung des Aktivitätenprotokollierungssystems erklärt,kann dieses auch technische Informationen über einen Kunden erfassen, wie z. B. die IP-Adresse. Anhand dieser kann eine Raumeingrenzung vorgenommen werden, sodass eineErkenntnis über den Kunden vorliegt, aus welcher geographischen Region dieser den Pro-duktkonfigurator aufgerufen hat. Derartiges Wissen kann z. B. im Rahmen des Marketingsgezielt verarbeitet und eingesetzt werden. Es sei an dieser Stelle dahingestellt, ob dieseDatenauswertung eine rechtliche Grundlage besitzt, da es einzig um das Aufzeigen der

4.5. SYNERGIEEFFEKTE 87

Möglichkeiten geht. Ein Beispiel für die Auswirkung der Auswertung derartiger Faktenist eine auf spezifische Regionen ausgerichtete Marketingkampagne, welche die bereitsvorhandene Bekanntheit eines Produktes stabilisiert und verstärkt. Die folgende Abbil-dung 4.17 stellt diesen Vorgang in schematischer Darstellung dar.

Interaktions-

werkDialogwerk

Aktivitäten-

protokollierungs-

system

Konfigurations-

daten

Integrator A

Kunden-

informationssysteme

Verkehrsdaten

Daten-

analyse

Datenextraktion

Un

terneh

men

(z.B. M

ark

etingabteilu

ng)

Abbildung 4.17: Kundenbezogene Erkenntnisgewinnung

4.5.3 Automatisierte Vertriebsunterstützung

Auch im Bereich der Vertriebsunterstützung lassen sich Synergieeffekte feststellen. So bil-det der Vorgang des Zusammenstellens eines Produktes in vielen Geschäftsfeldern dieunmittelbare Phase vor dem Bestellvorgang, sodass dieser durch eine entsprechende Kopp-lung der Systeme (u. a. das Bestellsystem als solches oder aber diverse Bezahlsysteme) inautomatisierter Weise durch den Produktkonfigurator initiiert werden kann. Dies hat denVorteil, dass der Kunde das konfigurierte Produkt direkt bestellen kann, wenn das Unter-nehmen diese Möglichkeit anbietet. Betrachtet man hierbei die mögliche psychologischeDenkweise eines Kunden, so lassen sich verkaufsfördernde Faktoren erahnen. Ein Kunde,der sein gewünschtes Produkt zusammengestellt hat und dieses nun sinngemäß wie aufeinem Präsentierteller liegen sieht, wird dieses vermutlich zeitlich eher bestellen, wenn erdie sofortige Möglichkeit hierzu hat. Eine Voraussetzung ist natürlich, dass er bereits miteinem Kaufinteresse den Produktkonfigurator aufgesucht hat bzw. sich dieses Interesse imLaufe der Produktzusammenstellung entwickelt und er so mit der Benutzung des Systemsletztlich ein bestimmtes Ziel, nämlich den Kauf des Produktes, verfolgt. Der Synergieeffektbei diesem Szenario liegt in der bereits erfolgten Persistierung der Konfigurationsdaten.Diese können im Falle einer Bestellung in aufbereiteter Form direkt an die Fertigungs-abteilung transferiert werden, sodass diese mit der Herstellung des Produktes gemäß desgültigen Konfigurationswunsches des Kunden beginnen kann.

4.5.4 Wissenserweiterte Kundenbetreuung

Ein weiterer Synergieeffekt in Hinblick auf die erfolgte Persistierung der Konfigurations-daten ist im Bereich der Kundenbetreuung zu finden. Für den Fall einer unterstützenden


Dienstleistung (d. h. Support, Wartung des Produktes oder Aktivitäten zur Gewährleis-tung) des Anbieters gegenüber dem Kunden können die Mitarbeiter direkt auf die jeweili-gen Konfigurationen des bestimmten Produktes zugreifen. Der zuständige Mitarbeiter hatdadurch in direkter Art und Weise die Möglichkeit, das vorliegende Produkt beispielswei-se auf Erweiterungsoptionen zu prüfen. Das Unternehmen hat also sofort einen Einblickin das spezifische Produkt des Kunden, wodurch die Dienstleistung auf ein effektiveresFundament gestellt wird.

Kapitel 5

Prozesse und deren Dependenz

In diesem Kapitel wird eine Auswahl von Prozessen vorgestellt, die im Sinne des integra-tiven Grundmodells in Produktkonfiguratoren von elementarer Bedeutung sind. Hierzuwerden in einem ersten Abschnitt die Begrifflichkeiten definiert und eine Notation vor-gestellt, mittels derer der Ablauf eines Prozesses darstellbar ist. Dem schließt sich dereigentliche Blick auf die ausgewählten Prozesse und deren Dependenz an.

5.1 Definition und Notation

Der Begriff des Prozesses ist dem lateinischen Wort processus entlehnt, welches für „Fort-gang“ und „Fortschreiten“ steht. Synonyme für den Prozessbegriff sind u. a. Verlauf, Ent-wicklung, Ablauf oder Vorgang. Er findet sich in diversen Gebieten der Forschung undWirtschaft wieder, sodass u. a. unterschieden werden kann in einen Prozess als

• chemische Reaktion,

• Ablauf eines Programms (im Sinne der Informatik) oder

• ein streitiges Verfahren vor Gericht (im Sinne der Rechtswissenschaft).

Eine Definition des Begriffes im Sinne der Wirtschaftswissenschaften (konkret der Pro-zessorganisation) findet sich in [FS05]. Darin wird der Begriff des Prozesses beschriebenals eine „Folge von Aktivitäten [. . . ], deren Ergebnis eine Leistung für einen externenund internen Kunden darstellt.“ Weiterhin definieren Feldmayer und Seidenschwarzdrei Eigenschaften eines Prozesses, die auch hinsichtlich der Betrachtung des integrativenGrundmodells von Bedeutung sind und im Folgenden genannt werden:

1. Ein Prozess transformiert einen definierten Input auf Basis abgrenzbarer Teilschrit-te in einen bezüglich Spezifikation und Qualität von den Bedürfnissen des externenbeziehungsweise internen Kunden abgeleiteten materiellen beziehungsweise immate-riellen Output.

2. Ein Prozess liegt organisationsstrukturell betrachtet im Querschnitt zu den funktio-nalen Einheiten.

89

90 KAPITEL 5. PROZESSE UND DEREN DEPENDENZ

3. Prozesse werden aus den Bedürfnissen externer und interner Kunden heraus gestaltetund bilden so das Fundament der durchgehenden Kundenorientierung.

Ein Prozess wird demnach in der vorliegenden Arbeit derart aufgefasst, dass ausgehendvon der Bereitstellung eines sogenannten Inputs, welcher in Form einer Aktivität (z. B.dem Klick eines Nutzers) oder dem Vorliegen von Daten spezifiziert ist, eine Abfolge vonAktionen ausgelöst werden, die einen sogenannten Output zum Ergebnis haben (siehehierzu die Abbildung 5.1). Als Output wird hierbei in gleicher Art und Weise entwedereine Aktivität oder eine Menge von Informationen verstanden. Die Gesamtheit der Abfolgevon Aktionen wird umgangssprachlich auch als Prozessablauf bezeichnet. Darüber hinausdient ein Prozess einem vordefinierten Ziel. Ein Beispiel hierfür ist der bereits in dieserArbeit erwähnte Konfigurationsprozess, der im Abschnitt 5.2.1 näher betrachtet wird.Dieser hat zum Ziel, dass der Kunde ein Produkt in seiner Zusammensetzung nach seineneigenen Wünschen und Vorstellungen gemäß der gegebenen Möglichkeiten variieren kann.

Folge von

AktivitätenInput

Output

Abbildung 5.1: Schematische Darstellung des Prozessbegriffes

Mit Blick auf die zweitgenannte Eigenschaft eines Prozesses lässt sich für die vorliegen-de Arbeit festhalten, dass die Prozesse nicht einzig innerhalb der Module ablaufen, son-dern mehrere Module des integrativen Grundmodells durch einen Prozess berührt werden.Auch hier lässt sich das Beispiel des Konfigurationsprozesses zur Erklärung heranziehen:Während der Zusammenstellung eines Produktes arbeiten so u. a. die Module Template-,Dialog- und Inferenzwerk miteinander und sorgen durch diese Interaktion dafür, dass dieFunktionsfähigkeit des Gesamtsystems gegeben ist.

Die dritte Eigenschaft beschreibt die Art und Weise, wie ein Prozess und damit auch seinAblauf definiert wird. So ist z. B. der detaillierte Ablauf der Produktkonfiguration abhän-gig davon, wie es für den zu erwarteten Kundenkreis am geeignetsten erscheint. Hierbeispielen u. a. die intuitive Bedienbarkeit und die logische Abfolge von Konfigurationsschrit-ten in Produktkonfiguratoren eine entscheidende Rolle, welche zu den im Abschnitt 2.2.4.1genannten Anforderungen aus Kundensicht zu zählen sind.

Der Prozessbegriff kann aber auch in anderer Hinsicht differenziert betrachtet werden.So findet sich in [FS05] eine Unterscheidung anhand des inhaltlichen Schwerpunktes desProzesses im Unternehmensumfeld in

• Managementprozesse,

• Geschäftsprozesse und

• Supportprozesse.

5.2. KUNDENSEITIGE PROZESSE 91

Erstere „bilden den Rahmen für die wertschöpfenden Prozesse des Unternehmens.“ Sie wer-den an den Zielen des Unternehmens ausgerichtet und haben zur Aufgabe, die Planungund Definition der Geschäfts- und Supportprozesse voranzutreiben. Geschäftsprozesse re-präsentieren dabei die wertschöpfenden Aktivitäten und die Supportprozesse dienen über-wiegend der Prozessunterstützung. Die in der vorliegenden Arbeit betrachteten Prozesseentsprechen den beiden letztgenannten Prozesstypen.

Ein weiterer zu definierender Begriff ist die Dependenz. Dieser ist abgeleitet aus demlateinischen Wort dependere und bedeutet sinngemäß „abhängig sein“. Im Rahmen dervorliegenden Arbeit ist unter der Dependenz eines Prozesses die Abhängigkeit zu verstehen,die dieser auf andere Prozesse bzw. Teilprozesse und Persistierungselemente hat.

Für die Darstellung der Prozesse, welche in kunden- und anbieterseitige Prozesse unter-schieden werden, wird im Fortlauf dieses Kapitels die folgende in Abbildung 5.2 darge-stellte Notation verwendet. Diese orientiert sich an der DIN 66001 über „Informationsver-arbeitung. Sinnbilder und ihre Anwendung“ [Wil03].

nein

ja

Input bzw. Output

Prozessschritt

Pfeil, der die Reihenfolge der Prozesse im

Prozessablauf und die Abhängigkeiten der

Prozesse anzeigt

Verzweigungssituation

Dokument, z.B. verwendete Dokumentation,

telefonische oder mündliche Absprachen

Daten, die z.B. aus Persistierungselementen

erfasst werden

Prozess, dessen detaillierte Darstellung aus

der vorliegenden Prozessdarstellung ausgegliedert

wurde

Abbildung 5.2: Notation zur Darstellung von Prozessen gemäß DIN 66001

5.2 Kundenseitige Prozesse

In diesem Abschnitt liegt der Fokus auf der Betrachtung von Prozessen, die vordergrün-dig mit den Aktivitäten des Kunden im Sinne des integrativen Grundmodells zusammenhängen. Als erstes sei an dieser Stelle der zentrale Vorgang der Produktzusammenstellungzu nennen, der die Hauptaufgabe des Produktkonfigurators aus Kundensicht darstellt undim Abschnitt 5.2.1 näher betrachtet wird. Im Folgeabschnitt wird dann mit dem Be-stellvorgang ein weiterer Prozess erläutert, der sich in bestimmten Szenarien direkt demKonfigurationsprozess anschließt.

Darüber hinaus gibt es eine Reihe weiterer Prozesse, auf die aber in dieser Arbeit nichtim Detail eingegangen wird. Stattdessen sei an dieser Stelle ein Vertreter exemplarischgenannt. So trägt z. B. der Entscheidungsprozess des Kunden eine wichtige Rolle im Ge-samtverlauf der Kundenaktivitäten, da seine Wahl der Entscheidungen letztlich zu einerfür ihn ansprechenden Konfiguration führen kann. Dies wirkt sich dementsprechend auchauf die Wahrscheinlichkeit für eine sich direkt anschließende Bestellung des Produktes (so


diese Möglichkeit gegeben ist) aus. Das besondere an diesem Prozess ist die starke psycho-logische Komponente, die im Prozessablauf darzustellen ist. Es liegt hier eine Vermischungder technischen und visuellen Gegebenheiten mit der psychologischen Denk- und Entschei-dungsweise des Kunden vor. In Bezug auf die Dependenz dieses Prozesses zeigt sich einestarke Abhängigkeit zum Konfigurationsprozess, da sich der Entscheidungsprozess an denzentralen Stellen des Konfigurationsvorgangs wiederfindet.

5.2.1 Konfigurationsprozess

Als Input für diesen in der Abbildung 5.3 dargestellten Vorgang der Produktzusam-menstellung dient eine sogenannte Kundenidentifizierung, die erfolgt, sobald der Kundeden Produktkonfigurator aufruft. Damit in Verbindung stehen u. a. Daten, die dazu die-nen, dem Kunden eine bereits erteilte Identifikationskennung, wie z. B. eine Session-ID,zuzuordnen oder eine neue Kennung zu erteilen. Im Anschluss daran kann der Kundezwischen zwei Startszenarien wählen: Konfiguration laden oder neue Konfiguration be-ginnen. Der Grund für die Berücksichtigung dieser Auswahlmöglichkeit im Prozessablaufliegt in der gewollten Allgemeingültigkeit des Prozesses bezogen auf die Nutzergruppen,wie z. B. Kunden oder Mitarbeiter des Unternehmens. Beide benötigen die Möglichkeitdes Ladens einer Konfiguration; Zweitere z. B. für die wissenserweiterte Kundenbetreuung(siehe hierzu Abschnitt 4.5.4).Hat sich der Nutzer für die Neukonfiguration entschieden, so beginnt der auch als rekursivzu bezeichnende Teil des Konfigurationsprozesses. Der Nutzer hat die Möglichkeit, sichdie zur Auswahl stehenden Produktkomponenten auflisten zu lassen oder aber in dieserMenge nach bestimmten Produktbestandteilen zu suchen. Das Ergebnis dieser Aktivitätliegt in der Auflistung der zur Auswahl stehenden Produktkomponenten vor. Der Nutzersteht nun vor der Entscheidungssituation, ob er eine Komponente selektiert oder nicht.Zugleich kann an dieser Stelle auch die Deselektion einer Komponente erfolgen, wenn derNutzer eine Auswahl rückgängig machen möchte. Für den Fall, dass der Nutzer keine Kom-ponente aus- oder abwählt, gelangt er im Konfigurationsprozess wieder zur Suche einerbzw. zur Auflistung der wählbaren Produktkomponenten. Wählt der Nutzer jedoch in derEntscheidungssituation eine Komponente, so erfolgt daraufhin die Prüfung der Abhängig-keitsbeschreibungen. Falls das Ergebnis negativ ist, so muss der Vorgang der Ab- oderAnwahl einer Produktkomponente wiederholt werden. Dazu gelangt der Nutzer wieder-um zur Suche bzw. Auflistung der Bestandteile. Ergibt die Prüfung dagegen ein positivesErgebnis, kann die aktuelle Konfiguration um die neue Komponente erweitert und damitaktualisiert werden.Im Falle der Entscheidung für das Laden einer Konfiguration wird diese nach einer po-sitiven Prüfung der Abhängigkeitsbeschreibungen für alle in der Zusammenstellung ent-haltenen Komponenten als aktuelle Konfiguration erfasst. Im Fall eines negativen Prüfer-gebnisses gilt die Verfahrensweise analog wie bei der Neukonfiguration. Es besteht zudemdie Möglichkeit, dass der Nutzer abhängig des Systems die Konfiguration an genau derStelle fortführen kann, an der er die Konfiguration nach dem letzten Speichervorgangverlassen bzw. abgebrochen hat. Es kann unter Umständen jedoch auch der Fall eintre-ten, dass eine gespeicherte Konfiguration nicht erfolgreich geladen werden kann, wenn diedarin enthaltenen Modelldaten bereits älterer Natur sind und nicht mehr durch das Sys-tem unterstützt werden (begrenzte Abwärtskompatibilität). Dieser Fall wird jedoch in derweiteren Betrachtung außen vor gelassen.

5.2. KUNDENSEITIGE PROZESSE 93

Kunden-

identifizierung

Konfiguration

laden?ja

Konfigura-

tionsdaten

Auflisten der zur

Auswahl

stehenden

Komponenten

nein

Konfiguration

aktualisieren

Konfiguration

(zwischen-)

speichern?

Konfiguration

vollständig?

Produkt-

komponente

suchen?

Produkt-

komponente

suchen

ja

nein

ja

nein

Bestell-

prozess

ungültig *

Selektion?

nein

Prüfung der

Abhängigkeits-

regeln

ja

gültig

neinPersistierung ja

nein

Konfiguration

bestellen?

ja

Gesamtübersicht

*: unter Voraussetzung einer vorhandenen Abwärtskompatibilität

Abbildung 5.3: Schematische Darstellung des Konfigurationsprozesses

In den beiden soeben beschriebenen Szenarien schließt sich nach der Aktualisierung derKonfiguration die Möglichkeit an, die aktuelle Zusammenstellung zwischenzuspeichern.Unabhängig von der Entscheidung kann die Fortführung der Produktzusammenstellungerfolgen. Nach der Persistierung wird im Prozessablauf ein Prozessschritt vorgesehen, derals „Konfiguration vollständig?“ bezeichnet ist. Dieser symbolisiert die unterschiedlichenArten des Konfigurationsverlaufs (siehe hierzu Abschnitt 3.2.3.2). So erfolgt z. B. bei deriterativen Konfiguration an dieser Stelle einfach das Umschalten auf den nächsten Konfigu-rationsschritt bzw. die Darstellung der Übersichtsseite. Ausgehend von dieser Übersichts-seite kann der Nutzer das zusammengestellte Produkt bestellen. Diese Möglichkeit bedarfjedoch immer der Voraussetzung, dass auch das anbietende Unternehmen eine derartigedirekte Bestellmöglichkeit wünscht. Entscheidet sich der Nutzer gegen eine Bestellung desProduktes, endet der Konfigurationsprozess mit einem leeren Output. Hierunter ist zuverstehen, dass sich keine direkte Aktivität anschließt.

Der Konfigurationsprozess weißt eine Reihe von Dependenzen auf. Diese finden sich vor al-lem im Bezug auf die Persistierungselemente wieder. So werden Modelldaten benötigt, umdie Produkte informativ darzustellen oder die Abhängigkeiten zu prüfen. Über den gesam-


ten Prozess hinweg werden Informationen aus den Persistierungselementen Verkehrsdaten,Konfigurationsdaten und Oberflächendaten benötigt. Eine direkte Prozessdependenz gibtes zum Bestellprozess, der im nächsten Unterabschnitt näher betrachtet wird.

5.2.2 Bestellprozess

Im weiteren Fortlauf der Produktzusammenstellung kann sich in direkter Weise der Bestell-prozess (siehe hierzu die Abbildung 5.4) anschließen, so es das anbietende Unternehmenunterstützt. Als Input gilt für diesen Vorgang eine Art Initialisierungssignal. Hiermit istgemeint, dass dieser Prozess entweder direkt aus dem Konfigurationsprozess aufgerufenoder durch einen gesonderten Aufruf (z. B. ausgehend von einer Prozedur oder in Formeines externen Funktionsaufrufs) initiiert wird.

Initialisierungs-

signal

Konfigurations-

daten

Konfiguration

gültig?ja

nein

Kunden-

information

Daten-

transformation

Fertigung

Kunden-

information

Komponenten

verfügbar?

ja

nein

Kunden-

information

Datenformat-

spezifikation

Kunden-

daten

Zeit X

warten?

nein

ja

Abbildung 5.4: Schematische Darstellung des Bestellprozesses

In einem ersten Schritt werden für das zu bestellende oder die zu bestellenden Produktedie Konfigurationsdaten geladen. Mit diesen stehen auch die Kundendaten im Zusammen-hang, sodass diese in gleicher Weise aus dem entsprechenden Persistierungselement abge-rufen werden. Es erfolgt im Anschluss daran nochmals eine Prüfung auf die Korrektheitder Konfiguration, um gegebenenfalls vorgenommenen Änderungen an den Modelldatenoder auftretenden Komplikationen entgegenzuwirken. Verläuft eine derartige Prüfung ne-gativ, so erfolgt eine Mitteilung an den Kunden, dass die zu bestellende Konfigurationnicht (mehr) gültig ist. Der Kunde muss in diesem Fall die Konfiguration abändern (siehehierzu Konfigurationsprozess im Abschnitt 5.2.1). Im Falle eines positiven Ergebnisses derPrüfung kann nun abgefragt werden, ob alle im Produkt enthaltenen Komponenten für diesich anschließende Zusammenstellung bzw. Fertigung auch tatsächlich vorrätig sind. Istdies nicht der Fall, gibt es aus Sicht des Kunden die Möglichkeit, eine bestimmte Zeit zuwarten, bis die Komponenten vorrätig sind. Die genaue Dauer ist durch das Unternehmen

5.3. ANBIETERSEITIGE PROZESSE 95

festzulegen und dem Kunden zu übermitteln. Bis alle Komponenten wieder verfügbar sind,befindet sich der Bestellprozess in einem Wartestatus. Möchte der Kunde allerdings nichtwarten, so wird der Bestellprozess an dieser Stelle abgebrochen und der Kunde erhält dar-über eine Information. Dies gilt auch für den Fall, dass eine Komponente überhaupt nichtmehr lieferbar ist. Der Unterschied hierbei liegt im Inhalt der Nutzerinformation, da dasUnternehmen spätestens in diesem Fall gut beraten ist, dem Kunden entsprechende Al-ternativvorschläge zu unterbreiten. Für den Fall, dass alle Produktbestandteile vorhandensind, können die Konfigurationsdaten entsprechend der Fertigungsmaschinen aufbereitetund parallel dazu der Kunde informiert werden, dass die Bearbeitung der Bestellung er-folgreich verlaufen ist. Für den Vorgang der Datentransformation bedarf es der vorherigenAbfrage der Datenformatspezifikation. Sobald die Transformation der Informationen alsabgeschlossen gilt, werden diese an die Fertigungssysteme übertragen. Es schließt sich derFertigungsprozess an.

5.3 Anbieterseitige Prozesse

Neben den kundenseitigen existieren auch eine Vielzahl anbieterseitiger Prozesse, die indiesem Abschnitt betrachtet werden. Als zentrale Vorgänge werden hierbei die Prozesse derProduktmodularisierung und der Pflege der Modelldaten im Detail vorgestellt. Darüberhinaus gibt es eine Reihe weiterer Prozesse, von denen an dieser Stelle auszugsweise einigegenannt seien.Zur Unterstützung des Kunden im Konfigurationsprozess gibt es die Möglichkeit der Ein-bindung eines Defaultwerkes (siehe hierzu auch Abschnitt 4.4.2.1). Hieraus bedingt ergibtsich z. B. der Prozess zur Generierung von Defaults. Dabei handelt es sich vor allem umanalysierende und auswertende Aktivitäten, die als Ergebnis eine Empfehlung für denKunden generieren. Ein derartiger Prozess weißt eine hohe Dependenz u. a. auf die Er-kenntnisse auf, die durch das Aktivitätenprotokollierungssystem (siehe hierzu Abschnitt4.3.1.3) erfasst und in den entsprechenden Persistierungselementen abgelegt werden.Ein weiterer anbieterseitiger Prozess hat die Visualisierung der Produktkomponenten zurAufgabe. Hierbei gelten als Inputdaten für den Prozess die Informationen über das Pro-dukt, d. h. die Texte zur Beschreibung der Produktkomponenten, aber vor allem auch dieMedien zur Darstellung der Bestandteile. Diese Informationen werden im Rahmen derProduktvisualisierung in eine spezifische Ordnung überführt, die dann zur Darstellungfür den Nutzer sichtbar gemacht werden. Auch die Generierung von Medien zur Laufzeit(siehe hierzu Abschnitt 3.2.3.9) entspricht einer Aufgabe dieses Prozesses.

5.3.1 Produktmodularisierung

Der in Abbildung 5.5 dargestellte Prozess der Produktmodularisierung bezieht sich zumeinen auf die Funktionsweise des integrativen Grundmodells, zum anderen aber auch aufden Prozess der Produktentstehung (siehe hierzu Abschnitt 2.1.5.2). Bevor ein Produktdurch einen Produktkonfigurator in dessen Zusammensetzung variiert werden kann, bedarfes einer Modularisierung (siehe hierzu Abschnitt 2.2.3). Aber auch für den Fall, dass einProdukt bereits in ein Konfiguratorsystem in Form seiner Modelldaten integriert wurde,bedarf es zur Erweiterung des Produktes um neue Komponenten eines erneuten Durch-führens des Modularisierungsprozesses bezogen auf die neuen Produktbestandteile. Aus


diesem Grund ist der in der vorliegenden Arbeit betrachtete Vorgang der Modularisierungauf eine abstrakte und damit allgemeine Sichtweise reduziert.

Produktdaten

Produkt-

spezifikation

zerlegbar?

ja

Komponenten-

mengenein

weitere

Komponenten

enthalten?

Komponenten-

spezifikation

definieren

ja

Komponenten-

spezifikationen

nein

weitere

Abhängigkeiten

vorhanden?ja

Abhängigkeits-

beschreibung

definieren

Produktdaten

nein

Abbildung 5.5: Schematische Darstellung des Prozesses zur Produktmodularisierung

Der Input des Prozesses entspricht den vorliegenden Produktdaten. Darauf aufbauendwird in einem zyklischen Vorgang eine Spezifikation des Produktes angelegt. Hierfür er-folgt eine Prüfung des Produktes auf zerlegbare Komponenten, d. h. es wird untersucht, obsich das Produkt in (weitere) Produktkomponenten zerteilen lässt (siehe hierzu auch dieDefinition 1 des Produktbegriffes). Kommt die Prüfung zu dem Ergebnis, dass aus der be-stehenden Zusammensetzung heraus keine weiteren Komponenten definierbar sind, so istder Zustand erreicht, bei dem gilt, dass alle atomaren Produktkomponenten des Produk-tes definiert wurden. An dieser Stelle sei darauf hingewiesen, dass sich die Atomarität derProduktkomponenten hierbei auf die für die Nutzung des Produktes in einem Konfigura-torsystem sinnvolle Granularität beschränkt. Es geht hier also nicht um die Zerlegung desProduktes in die fertigungsbezogenen Bestandteile. Nach Abschluss dieses Vorgangs liegtnun eine Menge von Komponenten des Produktes vor. Diese werden wiederum in einemzyklischen Vorgang spezifiziert, sodass am Ende des Teilprozesses für jedes Bestandteileine genaue Spezifikation vorhanden ist. Ausgehend von dieser Menge erfolgt nun einePrüfung der Komponenten untereinander, welche Abhängigkeiten zwischen den einzelnenProduktbestandteilen bestehen. Diese werden in einem weiteren Teilprozess definiert. AlsOutput dieses Prozesses werden die nun modifizierten Produktdaten (Modelldaten) zurPersistierung ausgegeben.

Hinsichtlich der Dependenzen dieses Prozesses lässt sich feststellen, dass vor allem derZugriff auf das Persistierungselement Modelldaten einen zentralen Charakter einnimmt.Aber auch die Logik des Produktkonfigurators, d. h. die zur Prüfung der Abhängigkeitennotwendige Konfigurationssprache, ist von zentraler Bedeutung für den Prozess, da die

5.3. ANBIETERSEITIGE PROZESSE 97

Modularisierung mit den technischen Möglichkeiten des Konfiguratorsystems einer Ab-stimmung bedarf.

5.3.2 Pflege der Modelldaten

Der zweite im Detail zu betrachtende anbieterseitige Prozess regelt den Ablauf der Mo-delldatenpflege. Eine schematische Darstellung des Prozessablaufs findet sich in der Ab-bildung 5.6. Diese Prozessdarstellung beschränkt sich dabei auf die Pflege eines bereitsim System existierenden Produktes.

Initialisierungs-

signal

Eingabe der

Zugangsdaten

Zugangsdaten

richtig?nein

Auswahl des

Produktes

ja

Produktdaten

laden

Modifizierung Persistierung?

Persistierung

ja

neinModifizierung

beenden?

Abmelden des

Nutzersja

Nutzer-

information

nein

Nutzer-

information

Nutzer-

information

Abbildung 5.6: Schematische Darstellung des Prozesses zur Modelldatenpflege

Der Start des Prozesses erfolgt durch das in Abschnitt 5.2.2 erläuterte Initialisierungssi-gnal. Ausgehend von diesem ist die Eingabe der Zugangsdaten durch den Nutzer erfor-derlich, da die Pflege der Modelldaten nur für autorisierte Mitarbeiter vorgesehen ist. Dieeingegebenen Informationen werden dann auf deren Korrektheit überprüft. Bei einem ne-gativen Prüfergebnis ist eine nochmalige Eingabe der Zugangsdaten erforderlich. Zudemwird der Nutzer über die inkorrekte Eingabe der Zugangsdaten in Kenntnis gesetzt. DieserTeilabschnitt des Prozesses ist rekursiver Art. Dabei ist eine Begrenzung der Rekursion,d. h. wie oft die Zugangsdaten eingegeben werden dürfen, systemspezifisch definierbar.Nach der erfolgreichen Autorisierung des Nutzers kann in einem Teilprozess nun das zumodifizierende Produkt ausgewählt werden. Dieses erfolgt z. B. in Form einer Selektion


aus einer Übersichtsliste oder in Form einer Produktsuche. Es schließt sich das Laden dererforderlichen Modelldaten für das Produkt an. Wenn diese Daten im System vorliegen,kommt der eigentliche Kern des Prozesses zur Geltung: die Modifizierung der Produkt-daten. Hierbei werden nun entweder einzelne Wertbelegungsmöglichkeiten der Produkt-komponenten, Beschreibungen oder aber auch Abhängigkeitsbeschreibungen geändert. Diekonkrete Form der Modifizierung spielt an dieser Stelle keine zentrale Bedeutung.Hat der Nutzer alle vorgesehenen Änderungen durchgeführt, können diese nun persistiertwerden. Der Nutzer hat nun die Möglichkeit, den Vorgang der Modifizierung zu beendenoder weitere Produkte in ihren Eigenschaften und Beschreibungen anzupassen. Bei Erste-rem erfolgt die Abmeldung des Nutzers aus dem System inklusive der Übermittlung einerNutzerinformation.Der Prozess der Modelldatenpflege weißt global betrachtet Dependenzen im Bereich derPersistierungselemente Modell-, Oberflächen- und Administrationsdaten auf. Bezüglichabhängiger Prozesse sei auf die Prüfung der Korrektheit der eingegebenen Zugangsdatenverwiesen, die einen Abgleichvorgang innerhalb des Berechtigungssystems erfordert. Auchfür die Persistierung bedarf es eines Prozesses, der für die ordnungsgemäße Ablage dergeänderten Daten sorgt.

Kapitel 6

Zusammenfassung und Ausblick

In diesem Kapitel wird die vorliegende Arbeit zusammengefasst. Außerdem werden einigeThemenvorschläge unterbreitet, die in weiterführenden wissenschaftlichen Ausarbeitungenbetrachtet werden können.

6.1 Zusammenfassung

Das zentrale Ziel der vorliegenden Arbeit bestand in dem Entwurf eines integrativenGrundmodells für Produktkonfiguratoren.Hierzu wurden in einem ersten Schritt die relevanten Grundlagen aufbereitet und darge-legt. Neben den Begriffen des Produktes, der Produktion und des Produktmodells galt esdie Merkmale der Themenbereiche Produkte und deren Herstellung, Produktkonfigurato-ren und der Unternehmensintegration themenspezifisch aufzuarbeiten. Über die gesamteArbeit hinweg lag der Fokus dabei nicht nur auf den materiellen, sondern auch auf denimmateriellen Produkten, die hinsichtlich der Produktkonfiguration zunehmend an Be-deutung gewinnen werden. Besondere Aufmerksamkeit galt zudem den unterschiedlichenVerfahren der Produktfertigung, welche auf die Eignung für die individuelle Produktzu-sammenstellung untersucht wurden. Bezüglich der Fertigungsverfahren ist hier vor allemdie kundenindividuelle Mehrfachfertigung, aber auch die Variantenfertigung unter Berück-sichtigung der unterschiedlichen Definitionsansätze zu nennen. Darüber hinaus wurdendie für die Produktkonfiguration zentralen Vorgänge der Produktmodularisierung und derDefinition konsistenter Abhängigkeitsbeschreibungen spezifiziert. Eine wichtige Rolle nah-men zudem die grundlegenden Anforderungen an Produktkonfiguratoren ein, welche ausSicht der Kunden sowie der Anbieter definiert wurden. Neben der Erläuterung des für dieweiteren Ausführungen wichtigen MVC-Architekturmusters erfolgte zusätzlich auch dieBeschreibung von drei Anwendungsbeispielen, um die praktische Relevanz von Produkt-konfiguratoren aufzuzeigen.Als ein Ergebnis des Modellbildungsprozesses wurde in einem zweiten Schritt eine Global-klassifikation vorgestellt. Diese zeigte anhand von vier Kategorien und insgesamt 24 Di-mensionen die breite Vielfalt, die es derzeit für Produktkonfiguratoren zu verzeichnen gibt.Auch wurde hierbei deutlich, dass es für den Entwurf eines Grundmodells einer Vielzahlan Abstrahierungsvorgängen bedarf, damit das Grundmodell in seiner finalen Zusammen-setzung den definierten Anforderungen von Produktkonfiguratoren gerecht werden kann.

99

100 KAPITEL 6. ZUSAMMENFASSUNG UND AUSBLICK

Zusätzlich wurden die in einem derartigen Konfiguratorsystem relevanten Daten anhandeiner erweiterten datensemantischen Klassifikation differenziert. Diese zeigte vor allem dieVielseitigkeit und den Informationsgehalt von Daten auf, die in einem Produktkonfiguratorerzeugt und erfasst werden.Darauf aufbauend erfolgte in einem dritten Schritt die Vorstellung des integrativen Grund-modells für Produktkonfiguratoren als zentrales Ergebnis der Arbeit. Hierzu mussten ein-führend die grundlegende Begrifflichkeiten definiert und die Vorgehensweise des Modell-entwurfes erklärt werden. Dem schloss sich die Spezifizierung der im Grundmodell ent-haltenen Module an, wobei der Blick insbesondere auf die Funktionsweise, die Interaktionder Komponenten untereinander und die Datenzugriffe der Module auf die entsprechendenSpeichereinheiten gerichtet war. Zur Überprüfung der Erfüllung der Anforderungen an dasModell wurde sowohl eine Anwendungs- als auch eine Anforderungsvalidierung durchge-führt. Ergänzend hierzu wurden weiterhin vier Synergieeffekte aufgezeigt, welche durchdie Integration von Konfiguratorsystemen herbeigeführt werden können.In einem vierten und letzten Schritt galt es, ausgewählte Prozesse zu betrachten und dieseauf deren Dependenz hin zu untersuchen. Hierbei lag der Fokus auf Vorgängen, die im Sinnedes integrativen Grundmodells für Produktkonfiguratoren von zentraler Bedeutung sind,beispielsweise der Konfigurationsprozess und der Vorgang der Produktmodularisierung.

6.2 Ausblick

Diese wissenschaftliche Arbeit hat insbesondere mit der Globalklassifikation und dem Ent-wurf eines integrativen Grundmodells für Produktkonfiguratoren eine theoretische Basisformuliert, auf die im Rahmen weiterführender wissenschaftlicher Ausarbeitungen aufge-baut werden kann. Derartige Themenvorschläge seien im Folgenden kurz angerissen.

Implementierung des integrativen Grundmodells

Das integrative Grundmodell wurde in der vorliegenden Arbeit in seiner Zusammensetzungund Funktionsweise formuliert. Zudem erfolgte eine Spezifizierung der Modulabhängigkei-ten und der Datenzugriffe auf die entsprechenden Speichereinheiten. Auch die Einord-nung der Module in das für eine Implementierung interessante MVC-Architekturmusterist Bestandteil der Ausführungen. Darauf aufbauend könnte in einer weiterführenden Ar-beit dieses Grundmodell implementiert werden, sodass ein Anwendungsprogramm ent-steht, welches die Basisfunktionen und Möglichkeiten eines (Grund-)Produktkonfiguratorsaufzeigt. Auch eine sich anschließende Verwendung des Programms als didaktisch auf-bereitetes Lern- und Demonstrationssystem ist aus meiner Sicht vorstellbar, da es dieZusammenhänge zwischen den unterschiedlichen Segmenten der Informatik einerseits undder Anwendung in der Wirtschaft andererseits sichtbar macht und so als Beispiel für dieinterdisziplinäre Wissensvernetzung dient.

Entwicklung eines Meta-Konfigurators

Ausgehend von dem Entwurf des integrativen Grundmodells könnte auf theoretischer Ebe-ne ein Meta-Konfigurator konzipiert werden, der die Aufgabe hat, mittels eines Konfigura-tionsprozesses bestimmte Module und Komponenten derartig zusammenzustellen, dass am

6.2. AUSBLICK 101

Ende des Vorgangs ein Produktkonfigurator entsteht, der sich wiederum für die Konfigu-ration der vorgesehenen Produkte eignet. Die Herausforderung hierbei liegt zum einen inder Spezifizierung der zahlreichen Module, die in Produktkonfiguratoren ihre Anwendungfinden, zum anderen aber vor allem in der Realisierung eines Integrationsansatzes, welcherdie individuelle Bündelung von Modulen gewährleistet und die technische Belastbarkeitberücksichtigt. Der Vorteil eines derartigen Systems liegt in der Komplexitätsbeherrschungund der damit einhaltenden Flexibilität in Bezug auf die Universalität des Konfigurators.

Studie zum gegenwärtigen Einsatz von Produktkonfiguratoren und deren In-tegrationsgrad

Der gegenwärtige Einsatz von Produktkonfiguratoren in der Wirtschaft und die hinsicht-lich der Globalklassifikation beschriebene Dimension des Integrationsgrades eignen sich alsErhebungsgrundlage für eine Studie. Zwar gibt es bereits einige Marktstudien, die eineneinführenden Überblick über die derzeit auf dem Markt operierenden Unternehmen aufzei-gen und über die Funktionalitäten der jeweiligen Konfiguratorprodukte Auskunft geben,die aber nicht vollumfänglich aus der wissenschaftlichen Sicht heraus angefertigt wurden.So könnte im Rahmen einer Ausarbeitung ein von der Wirtschaft unabhängiger Blick aufdie derzeitige Situation gerichtet und dabei untersucht werden, inwieweit die bestehendenKonfiguratorsysteme in der Praxis bereits in das Unternehmensumfeld technisch integriertsind.

Anforderungsvalidierung und Normierung von Produktkonfiguratoren

Eine weitere Untersuchung ist zum Thema der Anforderungsvalidierung und Normierungvorstellbar. Im Rahmen der Aufbereitung und Darlegung des Grundlagenwissens findetsich in der vorliegenden Arbeit auch eine Ausarbeitung der zentralen Anforderungen anProduktkonfiguratoren aus Sicht des Kunden und des Anbieters wieder. In der Praxis vor-handene Produktkonfiguratoren könnten so auf die Erfüllung dieser Anforderungen hinüberprüft werden, sodass ausgehend von dieser Untersuchung eine Art Qualifizierungssie-gel für existierende Konfiguratorsysteme vergeben werden könnte. Das integrative Grund-modell ist zudem auch als Referenzmodell für Produktkonfiguratoren anzusehen. Daraufaufbauend ist aus meiner Sicht vorstellbar, dass sich die Arbeit der Normierung von Kon-figuratorsystemen widmet. Konkret ist hierbei die Spezifizierung von Modulen und derenFunktionsweise gemeint, sodass ausgehend hiervon eine exakte und definitorisch verwert-bare Formulierung resultiert.

Eignung immaterieller Produkten in der Produktkonfiguration

Bereits im Grundlagenkapitel wurde darauf aufmerksam gemacht, dass die Verwendungvon immateriellen Produkten in der Produktkonfiguration zunehmend an Bedeutung ge-winnen wird. Im Rahmen einer wissenschaftlichen Ausarbeitung könnte eine grundlegendeUntersuchung vorgenommen werden, welche Arten immaterieller Produkte sich grundle-gend für die Verwendung in der Produktkonfiguration eignen, welche Schwierigkeiten es beider Modularisierung immaterieller Produkte zu überwinden gilt und welche Unterschiedees im Vergleich zur Konfiguration von materiellen Produkten gibt.

102 KAPITEL 6. ZUSAMMENFASSUNG UND AUSBLICK

Anhang A

Definitionen für„Produktkonfigurator“

„Die Produktkonfiguration beschreibt das Zusammensetzen eines Produktes aus vorgege-benen Produktkomponenten (sog. Selektion und Kombination) und die Selektion inhalt-licher Ausprägungen der Komponenteneigenschaften (sog. Parametrisierung) unter Ein-haltung der Konfigurationsregeln. Die Konfigurationsmöglichkeiten ergeben sich aus denSelektions-, Kombinations- und Parametrisierungsmöglichkeiten eines Produktes einge-schränkt durch die Konfigurationsregeln.“ [Sch06]

„Produktkonfigurator: Ein Werkzeug, das hilft ein Produkt so zu bestimmen, dass esvorgegebenen Eigenschaften genügt. Ein Produktkonfigurator kann auf verschiedene Weiseerstellt werden, er kann speziell programmiert werden oder es kann ein Werkzeug zu seinerErstellung benutzt werden. Die Software zur Erstellung eines Produktkonfigurators wirdals Konfigurationssoftware bezeichnet.“ [Bri99]

„Produktkonfiguratoren sind multifunktionale, rechnergestützte Systeme, die als Schnitt-stelle zwischen Vertrieb und wertschöpfungsnahen Funktionen stehen. Sie dienen zur in-formationstechnischen Wissens- und Aufgabenintegration mit dem Ziel, die Verkaufs- undAufgabenabwicklungsprozesse effektiv und effizient zu unterstützen.“ [KRA02]

„A product configurator is a tool which supports the product configuration process sothat all the design and configuration rules which are expressed in a product configurationmodel are guaranteed to be satisfied.“ [Mag98]

„Ein Produktkonfigurator ist ein computergestütztes System, mit dem der Kunde typi-scherweise über das Internet bzw. World Wide Web interagiert. [. . . ] Der Konfigurator bie-tet dem Kunden die Möglichkeit, im Rahmen eines Konfigurationsvorgangs die gewünsch-ten Produktmodule zu wählen sowie die Produktparameter nach Wunsch zu konkretisierenund wacht dabei über die Einhaltung der Produktregeln.“ [Pol08]

„Konfigurationssysteme stellen [. . . ] ein integrales Bindeglied zwischen Produktentwick-lung, Fertigung und Kundenwunsch dar. Ausgestattet mit einer einfachen Benutzerschnitt-stelle leiten diese Systeme den Kunden (und ggfs. einen Mitarbeiter im Verkauf) durchdie Erhebung der Bedürfnisinformation - und prüfen sogleich die Konsistenz sowie dieFertigungsfähigkeit der gewünschten Variante.“ [RP06]

103

104 ANHANG A. DEFINITIONEN FÜR „PRODUKTKONFIGURATOR“

„Ein Konfigurationssystem ist ein Expertensystem, das das Wissen der Konstrukteure ent-hält. Der Verkäufer kann damit im Verkaufsgespräch eine passende Produktkonfigurationfür den Kunden auswählen und sofort ein Angebot abgeben.“ [VMS10]„Bei einem Konfigurator handelt es sich um ein Computerprogramm, mit dem sich Pro-duktdetails kundenindividuell ändern und anpassen lassen. Mit einem Konfigurator kannder Kunde sein persönliches „Wunschprodukt“ zusammenstellen.“ [KG10]

Literaturverzeichnis

[Abe04] Helmut Abels. Kapitel Organisationsformen der Produktion der VorlesungProduktionsplanung und -steuerung I+II. (WS 2004/2005), FachhochschuleKöln, Fakultät für Fahrzeugsysteme und Produktion, Institut für Produktion,2004.

[Ame10] American Academy of Achievement. Craig McCaw Biography - Pioneer ofTelecommunications. http://www.achievement.org/autodoc/page/mcc0bio-1, letzter Aufruf: 01.06.2010.

[AWA05] Katrin Alisch, Eggert Winter und Ute Arentzen. Gabler Wirtschaftslexikon.Gabler, 2005.

[BAKF04] Thorsten Blecker, Nizar Abdelkafi, Gerold Kreutler und Gerhard Friedrich.Product Configuration Systems: State of the Art, Conceptualization and Ex-tensions. Technischer Bericht, Universität Klagenfurt, 2004.

[Bar94] Martin Bartuschat. Beitrag zur Beherrschung der Variantenvielfalt in derSerienfertigung. Dissertation, Technische Universität Braunschweig, 1994.

[Bar08] Michael Bartl. Open Innovation! HYVE AG, 2008.

[Bec06] Peter Becker. Kapitel Regelbasierte Systeme der Vorlesung Decision Supportund Expertensysteme. (SS 2006), Hochschule Bonn-Rhein-Sieg, LehrgebietWissens- und Informationsmanagement, 2006.

[BI97] Jürgen Bloech und Gösta B. Ihde. Vahlens Großes Logistiklexikon. Logistiktotal. Vahlen, 1997.

[Bie01] Christian Bieniek. Prozeßorientierte Produktkonfiguration zur integriertenAuftragsabwicklung bei Variantenfertigern. Dissertation, Technische Univer-sität Carolo-Wilhelmina zu Braunschweig, gem. Fakultät für Maschinenbauund Elektrotechnik, 2001.

[Bri99] Axel Brinkop. Variantenkonstruktion durch Auswertung der Abhängigkeitenzwischen den Konstruktionsbauteilen. Infix, St. Augustin, 1999.

[Bus10] Frank Buschmann. Pattern-orientierte Software-Architektur. Ein Pattern-System. Addison-Wesley, 2010.

[Cim08] Philipp Cimiano. Kapitel Überwachte Maschinelles Lernen Verfahren derVorlesung Maschinelles Lernen. (WS 07/08), Universität Heidelberg, 2008.

105

106 LITERATURVERZEICHNIS

[Det02] Walter Dettling. EAI oder die Sehnsucht nach einer heilen Welt. In Netz-guide: Enterprise Application Integration, 2002.

[Die10] Sebastian Dietrich. OO Architekturen. PediaPress, 2010.

[DMMW03] Stefan Deßloch, Albert Maier, Nelson Mattos und Dan Wolfson. InformationIntegration - Goals and Challenges. Datenbank-Spektrum, 2003.

[DS05] Wolfgang Domschke und Armin Scholl. Grundlagen der Betriebswirtschafts-lehre. Eine Einführung aus entscheidungsorientierter Sicht. Springer, Berlin,2005.

[ES08] Martin Eigner und Ralph Stelzer. Product Lifecycle Management. Springer,2008.

[Fan05] Günter Fandel. Produktion 1. Produktions- und Kostentheorie. Springer-Verlag GmbH, 2005.

[Fra02] Hans-Joachim Franke. Variantenmanagement in der Einzel- und Kleinseri-enfertigung. Fachbuchverlag Leipzig, 2002.

[FS05] Johannes Feldmayer und Werner Seidenschwarz. Marktorientiertes Prozess-management. Franz Vahlen München, 2005.

[Göb09] Andreas Göbel. Internationalisierung in Produktkonfiguratoren - Anforde-rungen und Konzepte für die Datenhaltung. Diplomarbeit, Friedrich-Schiller-Universität Jena, Lehrstuhl für Datenbanken und Informationssysteme, 2009.

[Gli05] Martin Glinz. Kapitel Einführung in die Modellierung der Vorlesung Infor-matik II: Modellierung. (SS 2005), Universität Zürich, Institut für Informatik,2005.

[GT09] Hans-Otto Günther und Horst Tempelmeier. Produktion und Logistik. Sprin-ger, Berlin, 2009.

[Har09] Douglas Harper. Online Etymology Dictionary. http://www.etymonline.com,2009.

[Hei04] Oliver Heidbach. Definition und Klärung des Begriffs „Modell“. HelmholtzGeoForschungsZentrum (GFZ) Potsdam, 2004.

[HK08] Michael Herczeg und Martin Christof Kindsmüller. Mensch und Computer2008: 8. fachübergreifende Konferenz für interaktive Medien - Viel Mehr In-teraktion. In Interaction Patterns für Produktkonfiguratoren, 2008.

[HR83] Theo Haerder und Andreas Reuter. Principles of transaction-oriented data-base recovery. Technischer Bericht, ACM New York, 1983.

[HSS07] Andreas Heuer, Gunter Saake und Kai-Uwe Sattler. Datenbanken. Konzepteund Sprachen. Mitp-Verlag, 2007.

[IL00] Sheena S. Iyengar und Mark R. Lepper. When Choice is Demotivating: CanOne Desire Too Much of a Good Thing? In Journal of Personality and SocialPsychology, Vol. 79, 2000.

LITERATURVERZEICHNIS 107

[Jun06] Hans Jung. Allgemeine Betriebswirtschaftslehre. Oldenbourg Wissenschafts-verlag, 2006.

[Kai02] Michael Kaib. Enterprise Application Integration - Grundlagen, Integrati-onsprodukte, Anwendungsbeispiele. Dissertation, Universität Marburg, 2002.

[KASW06] Philip Kotler, Gary Armstrong, John Saunders und Veronica Wong. Grund-lagen des Marketing. Pearson Studium, 2006.

[Kay93] Alan C. Kay. The early history of Smalltalk. In ACM SIGPLAN notices,1993.

[Kem09] Alfons Kemper. Datenbanksysteme: Eine Einführung. Oldenbourg, 2009.

[KG10] Welke Consulting GmbH & Co. KG. http://www.welke-consulting.de/index.php?id=55, letzter Aufruf: 02.06.2010.

[Küp09] Hans-Ulrich Küpper. Kapitel Grundlagen der Vorlesung Produktion undOrganisation. (WS 2009/2010), Institut für Produktionswirtschaft und Con-trolling, Ludwig-Maximilians-Universität München, 2009.

[KRA02] Rolf-Dieter Kempis, Jürgen Ringbeck und R. Augustin. Do IT smart. Ue-berreuter Wirt., F., 2002.

[Kru09] Andreas Krug. Untersuchung verschiedener Replikationsverfahren unter IBMDB2 LUW am konkreten Beispiel der Digitalen Bibliothek der Friedrich-Schiller-Universität Jena und des Freistaates Thüringen. Studienarbeit,Friedrich-Schiller-Universität Jena, Lehrstuhl für Datenbanken und Informa-tionssysteme, 2009.

[KS02] Klaus-Peter Kistner und Marion Steven. Betriebswirtschaftslehre im Grund-studium 1: Produktion, Absatz, Finanzierung. Physica-Verlag, 2002.

[Küs10] Klaus Küspert. Kapitel Einleitung und Motivation der Vorlesung Daten-banksysteme 1. (WS 09/10), Friedrich-Schiller-Universität Jena, Lehrstuhlfür Datenbanken und Informationssysteme, 2010.

[KT79] D. Kahneman und A. Tversky. Prospect theory: An analysis of decision underrisk. Technischer Bericht, Econometrica, 1979.

[Lec06] Thomas Leckner. Kundenkooperation beim Web-basierten Konfigurieren vonProdukten. Josef Eul Verlag, 2006.

[Lie03] Matthias Liebisch. Synchronisationskonflikte beim mobilen Datenbankzu-griff: Vermeidung, Erkennung und Behandlung. Diplomarbeit, Institut fürInformatik, Friedrich-Schiller-Universität Jena, Februar 2003.

[Lie08] Matthias Liebisch. Datenhaltung in Konfiguratoren - ein Überblick. Techni-scher Bericht, Friedrich-Schiller-Universität Jena, Lehrstuhl für Datenbankenund Informationssysteme, 2008.

[Lie09] Matthias Liebisch. Architekturen für Produktkonfiguratoren - Anforderungenund Konzepte. Vortrag, Friedrich-Schiller-Universität Jena, Lehrstuhl fürDatenbanken und Informationssysteme, 2009.


[Lin95] Heinz Linß. Integrationsabhängige Nutzeffekte der Informationsverarbeitung- Vorgehensmodell und empirische Ergebnisse. Wiesbaden, 1995.

[Mag98] Boris Magnusson. System Configuration Management, ECOOP’98 SCM-8Symposium, Brussels, Belgium, July 20-21, 1998, Proceedings. Springer, Ber-lin, 1998.

[Mel05] Ingo Melzer. Service-orientierte Architekturen mit Web Services. SpektrumAkademischer Verlag, 2005.

[Mil09] George A. Miller. WordNet. Princeton University. (Search Term: product).http://wordnet.princeton.edu, 2009.

[Min68] M. Minsky. Matter, Mind, and Models. In Semantic Information Processing.Cambridge, Mass.: MIT Press, 1968.

[Pol08] Benjamin Polak. Kundenorientierte Gestaltung von Produktkonfiguratoren.Dissertation, Universität St. Gallen, Hochschule für Wirtschafts-, Rechts- undSozialwissenschaften, 2008.

[Ree79] Trygve Reenskaug. Thing-Model-View-Editor . Technischer Bericht, XeroxPARC, 1979.

[Ree03] Trygve Reenskaug. The Model-View-Controller (MVC) - Its Past and Pre-sent. Technischer Bericht, Universität zu Oslo, 2003.

[Rüh09] Doris Rührig. Integrationsprobleme bei internationalen Unternehmenszusam-menschlüssen. Diplomarbeit, Universität Wien, Fakultät für Wirtschaftswis-senschaften, 2009.

[Ros09] Wilhelm R. Rossak. Vorlesung Objektorientierte Analyse und Design. (SS2009), Friedrich-Schiller-Universität Jena, Lehrstuhl für Softwaretechnik,2009.

[RP03] Timm Rogoll und Frank T. Piller. Konfigurationssysteme für MassCustomization und Variantenproduktion. ThinkConsult, München, 2003.

[RP06] Ralf Reichwald und Frank T. Piller. Interaktive Wertschöpfung. Open In-novation, Individualisierung und neue Formen der Arbeitsteilung. Gabler,2006.

[Run06] Wolfgang Runte. YACS: Ein hybrides Framework für Constraint-Solver zurUnterstützung wissensbasierter Konfigurierung. Diplomarbeit, UniversitätBremen, Fachbereich Mathematik/Informatik, 2006.

[Sch02] Christoph Schneeweiß. Einführung in die Produktionswirtschaft. Springer,2002.

[Sch06] Christian Scheer. Kundenorientierter Produktkonfigurator: Erweiterung desProduktkonfiguratorkonzeptes zur Vermeidung kundeninitiierter Prozessab-brüche bei Präferenzlosigkeit und Sonderwünschen in der Produktspezifika-tion. Logos Berlin, 2006.

LITERATURVERZEICHNIS 109

[SG03] Günter Stock und Alexander Geyken. Das Digitale Wörterbuch der deutschenSprache des 20. Jahrhunderts. http://www.dwds.de, 2003.

[SSEM05] Werner Scholze-Stubenrecht, Birgit Eickhoff und Dieter Mang. Duden 05.Das Fremdwörterbuch. Bibliographisches Institut, Mannheim, 2005.

[Sta74] Herbert Stachowiak. Allgemeine Modelltheorie. Springer, Wien, 1974.

[Sta09] Rainer Stark. Kapitel Einführung der Vorlesung Grundlagen der Industriel-len Informationstechnik. (SS 2009), Institut für Produktionswirtschaft undControlling, Ludwig-Maximilians-Universität München, 2009.

[SWD03] Petra Schubert, Ralf Wölfle und Walter Dettling. E-Business-Integration -Fallstudien zur Optimierung elektronischer Geschäftsprozesse. Hanser, 2003.

[Tho02] Marco Thomas. Informatische Modellbildung - Modellieren von Model-len als ein zentrales Element der Informatik für den allgemeinbildendenSchulunterricht. Technischer Bericht, Universität Potsdam, Mathematisch-Naturwissenschaftliche Fakultät, 2002.

[VDI00] VDI. Simulation von Logistik-, Materialfluß- und Produktionssystemen -Grundlagen. Technischer Bericht, VDI-Richtlinien, 2000.

[VMS10] VMS Vertriebs- und Marketing- Services GmbH. http://www.vms-gmbh.com/kompetenz/glossar.php, letzter Aufruf: 01.06.2010.

[Wil03] Rudolf Wilhelm. Prozessorganisation. Oldenbourg Verlag, 2003.

[Wüp00] Josef Wüpping. Konfigurationstechnik für die individuelle Serienfertigung.IT Management, 2000.

[Zin03] Harry Zingel. Produktlebenszyklus und strategisches Marketing - Phasenbezo-gene Konzepte und Methoden des Produktmanagement, 2003.

Abbildungsverzeichnis

1.1 Kapitelübersicht der Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Rekursive Produkt-Komponenten-Zusammensetzung . . . . . . . . . . . . . 72.2 Klassifizierung der Produktarten nach Domschke . . . . . . . . . . . . . . . 102.3 Kundenauftragsfertigung in Anlehnung an [GT09] . . . . . . . . . . . . . . . 122.4 Lagerfertigung in Anlehnung an [GT09] . . . . . . . . . . . . . . . . . . . . . 122.5 Auftragsbezogene Fertigstellung in Anlehnung an [GT09] . . . . . . . . . . . 122.6 Phasen des Produktlebenszyklus nach Zingel . . . . . . . . . . . . . . . . . 162.7 Phasen des Produktlebenszyklus in Anlehnung an [ES08] . . . . . . . . . . . 172.8 Veränderungen der Produktentstehungsmethoden in Anlehnung an [ES08] 172.9 Produktkonfiguratoren als Bindeglied zwischen Kunden und Unternehmen 192.10 Einsatzbereiche und ihre wirtschaftlichen Beziehungen . . . . . . . . . . . . 202.11 Einfluss der Markt- und Fertigungsvarianz auf die Modularisierung . . . . . 222.12 Anforderungen an Produktkonfiguratoren . . . . . . . . . . . . . . . . . . . . 242.13 Architekturmuster MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.14 Grafische Benutzeroberfläche des CREALIS® Mentor . . . . . . . . . . . . . 312.15 Zusammenhang zwischen Integrationszustand und -vorgang nach [Lin95] . 342.16 Enterprise Application Integration . . . . . . . . . . . . . . . . . . . . . . . . 362.17 Business-to-Business Application Integration in Anlehnung an [SWD03] . . 372.18 Service-orientierte Architektur in Anlehnung an [Mel05] . . . . . . . . . . . 38

3.1 Klassifikationstentakel für Produktkonfiguratoren . . . . . . . . . . . . . . . 403.2 Klassifikationstentakel der Basiskonzeptkategorie . . . . . . . . . . . . . . . 413.3 Klassifikationstentakel der Datenmodellkategorie . . . . . . . . . . . . . . . . 443.4 Klassifikationstentakel der Präsentations- und Darstellungskategorie . . . . 483.5 Klassifikationstentakel der Logik- und Architekturkategorie . . . . . . . . . 543.6 Gegenüberstellung verschiedener Abhängigkeitsprüfungen . . . . . . . . . . 553.7 Beispielbezogener Entscheidungsbaum . . . . . . . . . . . . . . . . . . . . . . 57

111

112 ABBILDUNGSVERZEICHNIS

3.8 Beispielbezogener Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.9 Klassifikationstentakel zur Datensemantik in Produktkonfiguratoren . . . . 59

4.1 Zusammenhang zwischen einem Modell, dessen Original und der Umwelt . 624.2 Schritte der Modellierung in Anlehnung an [Gli05] . . . . . . . . . . . . . . . 634.3 Schema des integrativen Grundmodells . . . . . . . . . . . . . . . . . . . . . . 654.4 Funktionalität des Interaktionswerkes . . . . . . . . . . . . . . . . . . . . . . 674.5 Aufgabe des Pflegesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.6 Modul Steuerung im EAI-Kontext . . . . . . . . . . . . . . . . . . . . . . . . 694.7 Arbeitsweise des Aktivitätenprotokollierungssystems . . . . . . . . . . . . . 714.8 Funktionsprinzip des Datenaufbereitungssystems . . . . . . . . . . . . . . . . 724.9 Veranschaulichung von Abhängigkeitsarten im Grundmodell . . . . . . . . . 724.10 Abhängigkeiten des Moduls Interaktionswerk . . . . . . . . . . . . . . . . . . 734.11 Abhängigkeiten des Moduls Dialogwerk . . . . . . . . . . . . . . . . . . . . . 744.12 Abhängigkeiten des Moduls Pflegesystem . . . . . . . . . . . . . . . . . . . . 754.13 Datenzugriffe der Module auf die Persistierungselemente im integrativen

Grundmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.14 Schema des dritten Schrittes des Szenarios 1 . . . . . . . . . . . . . . . . . . 804.15 Schema des vierten Schrittes des Szenarios 2 . . . . . . . . . . . . . . . . . . 824.16 Produktbezogene Erkenntnisgewinnung . . . . . . . . . . . . . . . . . . . . . 864.17 Kundenbezogene Erkenntnisgewinnung . . . . . . . . . . . . . . . . . . . . . . 87

5.1 Schematische Darstellung des Prozessbegriffes . . . . . . . . . . . . . . . . . 905.2 Notation zur Darstellung von Prozessen gemäß DIN 66001 . . . . . . . . . . 915.3 Schematische Darstellung des Konfigurationsprozesses . . . . . . . . . . . . . 935.4 Schematische Darstellung des Bestellprozesses . . . . . . . . . . . . . . . . . 945.5 Schematische Darstellung des Prozesses zur Produktmodularisierung . . . . 965.6 Schematische Darstellung des Prozesses zur Modelldatenpflege . . . . . . . 97

Tabellenverzeichnis

2.1 Vergleich der Fertigungstypen in Anlehnung an [Abe04] . . . . . . . . . . . . 152.2 Kundeneinflusses bei unterschiedlicher Produktindividualität und Produkt-

komplexität sowie Einordnung der Kategorisierung der Produktart nachScheer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3 Anwendungsbeispiele für Produktkonfiguratoren im Vergleich . . . . . . . . 30

3.1 Vergleich von Datenbank und Dateisystem als Persistierungsebene . . . . . 46

4.1 Zuordnung der Persistierungselemente . . . . . . . . . . . . . . . . . . . . . . 674.2 Kunden- und anbieterseitige Anforderungsvalidierung . . . . . . . . . . . . . 83

113

114 TABELLENVERZEICHNIS

Abkürzungsverzeichnis

A2C Administration-to-Consumer - Geschäftsbeziehungen zwischen der Ver-waltung und dem Privatkunden

ACID Atomarität (atomicity), Konsistenz (consistency), Isoliertheit (isolation)und Dauerhaftigkeit (durability) - Eigenschaften von Transaktionen inDatenbankmanagementsystemen

ATO Assemble to Order - Auftragsbezogene Fertigstellung

B2B Business-to-Business - Geschäftsbeziehungen zwischen Unternehmen

B2C Business-to-Consumer - Geschäftsbeziehungen zwischen Unternehmen undPrivatkunden

BAPI Business Application Programming Interface - standardisierte Program-mierschnittstelle der SAP-Business-Objekte

BBAI Business-to-Business Application Integration - Konzept zur unternehmens-übergreifenden Integration von Geschäftsfunktionen entlang der Wert-schöpfungskette

C2C Consumer-to-Consumer - Geschäftsbeziehungen zwischen Privatkunden

COM Component Object Model - eine von Microsoft entwickelte Plattformtech-nik, um unter dem Betriebssystem Windows Interprozesskommunikationund dynamische Objekterzeugung zu ermöglichen

CRM Customer Relationship Management - Kundenbeziehungsmanagement

CSV Comma-Separated Values - Dateiformat

cXML commerce eXtensible Markup Language - ein von der Firma Ariba Inc.entwickeltes XML-Format

DBMS Datenbankmanagementsystem

DIN Deutsches Institut für Normung

EAI Enterprise Application Integration - Konzept zur unternehmensweiten In-tegration von Geschäftsfunktionen entlang der Wertschöpfungskette

EDIFACT Electronic Data Interchange For Administration, Commerce and Trans-port - Branchenübergreifender internationaler Standard für das Formatelektronischer Daten im Geschäftsverkehr

115

116 ABKÜRZUNGSVERZEICHNIS

ERP Enterprise Resource Planing - Planung [des Einsatzes/der Verwendung]der Unternehmensressourcen

HSPA High Speed Packet Access - Mobilfunkstandard

HTTP HyperText Transfer Protocol - Protokoll zur Übertragung von Daten überein Netzwerk

Idoc Intermediate document - SAP-basiertes Dateiformat für Geschäftstrans-aktionen

IP Internet Protocol - Netzwerkprotokoll

LDAP Lightweight Directory Access Protocol - Anwendungsprotokoll aus derNetzwerktechnik zur Abfrage und Modifikation von Informationen einesVerzeichnisdienstes

LHS Left-Hand-Side - Aussage bzw. Formel innerhalb des Bedingungsteils beiregelbasierten Systemen

LLC Life Cycle Costing - Methode für das Produktkostenmanagement

LTE Long Term Evolution - Mobilfunkstandard neuester Generation (Stand:06/2010)

MAC Media-Access-Control - Hardware-Adresse eines Netzwerkadapters

MSMQ Microsoft Message Queuing - Technologie zur nachrichtenorientierten asyn-chronen oder synchronen Kommunikation

MTO Make To Order - Kundenauftragsfertigung

MTS Make To Stock - Lagerfertigung

MVC Model-View-Controller - Architekturmuster

openTRANS offener Standard zur Unterstützung des elektronischen Datenaustauschsbei Geschäftstransaktionen

PARC Palo Alto Research Center - Xerox Forschungszentrum

PEP Produktentstehungsprozess

PL1 Prädikatenlogik erster Stufe

RFC Remote Function Call - Verfahren, mit dem Funktionen in einem entfern-ten System aufgerufen werden

RHS Right-Hand-Side - Aussage bzw. Formel innerhalb des Aktionsteils beiregelbasierten Systemen

RPC Remote Procedure Call - Technik zur Realisierung von Interprozesskom-munikation

SOA Service-Orientierte Architektur

ABKÜRZUNGSVERZEICHNIS 117

SOAP Simple Object Access Protocol - Netzwerkprotokoll, mit dessen Hilfe Da-ten zwischen Systemen ausgetauscht und Remote Procedure Calls durch-geführt werden können

SWIFT Society for Worldwide Interbank Financial Telecommunication - Interna-tionale Genossenschaft der Geldinstitute, die ein Telekommunikationsnetzfür den Nachrichtenaustausch zwischen den Mitgliedern betreibt

VDI Verein Deutscher Ingenieure

W3C World Wide Web Consortium - Gremium zur Standardisierung der dasWorld Wide Web betreffenden Techniken

WLAN Wireless Local Area Network - lokales Funknetz

WSDL Web Service Definition Language - eine plattform-, programmiersprachen-und protokollunabhängige Beschreibungssprache für Netzwerkdienste (Webser-vices) zum Austausch von Nachrichten auf Basis von XML

xCBL XML Common Business Library - proprietäres XML-Format für Business-to-Business-Transaktionen

XML eXtensible Markup Language - Auszeichnungssprache zur Darstellung hier-archisch strukturierter Daten in Form von Textdaten

118 ABKÜRZUNGSVERZEICHNIS

Erklärung

Ich erkläre, dass ich die vorliegende Diplomarbeit selbstständig und nur unter Verwen-dung der angegebenen Quellen und Hilfsmittel angefertigt habe.

Jena, den 10. Juni 2010

EntwurfeinesintegrativenGrundmodells fürProduktkonﬁguratoren · 2018. 8. 10. · 1.1 Motivation...

Documents

Transcript of EntwurfeinesintegrativenGrundmodells fürProduktkonﬁguratoren · 2018. 8. 10. · 1.1 Motivation...