Integration von SAP Beziehungswissen in den Endress+Hauser ... · Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator Bachelorarbeit für die Prüfung zum Bachelor

Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator

Bachelorarbeit

für die Prüfung zum

Bachelor of Science

des Studiengangs Wirtschaftsinformatik Software-Engineering

an der

Dualen Hochschule Baden-Württemberg Lörrach

Frederik Frey

14. September 2015

Kurs WWI12a

Ausbildungsfirma Endress+Hauser InfoServe GmbH+Co. KG,

Weil am Rhein

Betreuer der Ausbildungsfirma Frau Christine Eichkorn

Wissenschaftlicher Betreuer Herr Prof. Gerhard Staib


I

Ehrenwörtliche Erklärung

Hiermit erkläre ich, dass ich die vorliegende Arbeit mit dem Thema


selbstständig und ohne Benutzung anderer als der angegebenen Quellen und

Hilfsmittel angefertigt habe.

Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten und nicht

veröffentlichten Schriften entnommen wurden, sind als solche kenntlich gemacht.

Die Arbeit ist in gleicher oder ähnlicher Form oder auszugsweise im Rahmen einer

anderen Prüfung noch nicht vorgelegt worden.

Weil am Rhein, 11. September 2015

Frederik Frey

Hinweis zum Umfang der Arbeit

Der Textteil der vorliegenden Arbeit - beginnend mit der Einleitung bis ausschließlich

Quellenverzeichnis - umfasst 60 Seiten.


II

Freigabe der Arbeit

Die vorliegende Arbeit wurde durch das Ausbildungsunternehmen

Endress+Hauser InfoServe GmbH+Co. KG, Weil am Rhein inhaltlich geprüft und zur

Vorlage an der DHBW Lörrach, Studiengang Wirtschaftsinformatik Software-

Engineering, freigegeben.

________________________________ _________________________________

Weil am Rhein, 11. September 2015 Christine Eichkorn


III

Abstract

Jeder hat ihn schon einmal bedient und seine Funktionen zu schätzen gewusst. Ob

beim Autokauf oder der Zusammenstellung der neuen Küche: ein Konfigurator.

Ein Konfigurator bietet die Möglichkeit mit wenigen Klicks von einer Vorstellung zu

einem fertig modellierten Produkt zu gelangen. Er soll bei der Wahl der richtigen

Konfiguration unterstützen und als Ergebnis eine vollkommen eindeutige Spezifikation

präsentieren, auf deren Basis die Produktion sofort beginnen kann.

Als global agierender Anbieter für Messgeräte setzt sich Endress+Hauser intensiv mit

der Konfiguration von Produkten auseinander. In den letzten Jahren wurden dabei

große Fortschritte erzielt und mit dem Release des neuen Endress+Hauser

Konfigurators 6.0 ist nun eine Version verfügbar, die den SAP Konfigurator, der die

letzten Jahre hauptsächlich genutzt wurde, abgelöst hat.

Trotzdem wird das SAP System weiter genutzt, da es komplexe Berechnungen,

aufbauend auf dem eingepflegten Beziehungswissen, erlaubt. Nur so kann die

Produzierbarkeit der Produkte gewährleistet werden. Das Ziel dieser Arbeit ist, dieses

Beziehungswissen auch im Endress+Hauser Konfigurator nutzen zu können.

Als IT-Dienstleister der Endress+Hauser Gruppe ist es die Aufgabe von Endress+Hauser

InfoServe eine Lösung für diese Problematik zu finden. Nun soll betrachtet werden, in

wie weit es möglich ist, das bereits im SAP vorhandene Wissen in den Endress+Hauser

Konfigurator 6.0 zu integrieren.

Ein erster Test verlief erfolgreich, denn es war möglich aus dem Endress+Hauser

Konfigurator 6.0 eine Validierung der aktuellen Konfiguration mit Hilfe des SAP

Beziehungswissen durchzuführen. Somit ist es nun möglich, bereits während der

Konfiguration eines Produkts die technische Umsetzbarkeit zu überprüfen.


IV

Inhaltsverzeichnis

Ehrenwörtliche Erklärung I

Hinweis zum Umfang der Arbeit I

Freigabe der Arbeit II

Abstract III

Inhaltsverzeichnis IV

Abkürzungsverzeichnis VI

Tabellenverzeichnis VII

Abbildungsverzeichnis VIII

1 Variantenkonfiguration 1

1.1 Die Komplexitäten 1

1.2 Die Herausforderungen 3

1.3 Das Bestreben 3

1.4 Der Ablauf 4

2 Stammdaten 6

2.1 Endress+Hauser 6

2.1.1 Endress+Hauser Product Center 6

2.1.2 Endress+Hauser Sales Center 7

2.1.3 Endress+Hauser InfoServe 7

2.2 Der Endress+Hauser Konfigurator 6.0 7

2.3 Varianten 9

2.3.1 Definition des Variantenbegriffs 9

2.3.2 Varianten und Standard 11

2.4 Variantenkonfiguration 13

2.5 Beziehungswissen 16

2.6 Methoden 22

2.6.1 Experteninterview 22

2.6.2 Risikoanalyse 22


V

2.6.3 Aufwandsschätzung 23

2.6.4 Business Process Model and Notation 24

2.6.5 Netzplantechnik 27

3 Der Wandel 30

3.1 Vergangenheit der Zukunft 30

3.2 Optimierungspotenzial 36

3.3 Zukunft der Vergangenheit 37

4 Evaluation 38

4.1 Allgemeines 38

4.2 Ansätze 40

4.2.1 Ansatz Eins 40

4.2.2 Ansatz Zwei 41

4.2.3 Ansatz Drei 42

4.2.4 Ansatz Vier 43

4.3 Aufwandsschätzung 43

4.3.1 Ansatz Eins 43

4.3.2 Ansatz Zwei 43

4.3.3 Ansatz Drei 44

4.3.4 Ansatz Vier 47

4.4 Auswahl 48

5 Das Projekt 49

5.1 Projektablauf 49

5.2 Entwicklung 52

5.3 Der neue Ablauf 54

6 Zurück in die Zukunft 57

6.1 Vergangenheit 57

6.2 Zukunft 58

Quellenverzeichnis IX

Anhang XIII


VI

Abkürzungsverzeichnis

CER Common Equipment Record

CRM Customer Relationship Management

ERP Enterprise Resource Planning

FAZ Frühste Anfang Zeit

FEZ Frühste Ende Zeit

FP Freier Puffer

GP Gesamtpuffer

PEA Project Engineering Assisten

SAZ Späteste Anfang Zeit

SEZ Späteste Ende Zeit

SBO SAP Business One

TSP Technisches Sonderprodukt

WBS Work Breakdown Structure


VII

Tabellenverzeichnis

Tabelle 1: Top 10 Automobilhersteller auf dem deutschen Markt, nach Anzahl der

Modellvarianten ............................................................................................................... 1

Tabelle 2 - Aufwandsberechnung Ansatz 3 .................................................................... 45

Tabelle 3 - Risikobewertung Ansatz 3............................................................................. 46

Tabelle 4 - Aufwandsschätzung Ansatz 4 ....................................................................... 47

Tabelle 5 - Risikobewertung Ansatz 4............................................................................. 48

Tabelle 6 - Legende Netzplan ......................................................................................... 49


VIII

Abbildungsverzeichnis

Abbildung 1 - Endress+Hauser Konfigurator 6.0 .............................................................. 9

Abbildung 2 - Prinzipielles Vorgehen bei der Variantenkonfiguration .......................... 14

Abbildung 3 – Beispiel für einen gerichteten, endlichen und kreisfreien Graphen ....... 27

Abbildung 4 - Ausgangsstatus einer Produktkonfiguration ........................................... 31

Abbildung 5 - Spezifizierung von frei wählbaren Merkmalswerten ............................... 32

Abbildung 6 - Fehlerhafte Konfiguration ........................................................................ 33

Abbildung 7 - Vollständige Konfiguration....................................................................... 33

Abbildung 8 - Bestellprozess via Online Shop ................................................................ 35

Abbildung 9 - Omnigrad M TR10 .................................................................................... 39

Abbildung 10 - Aufruf eines SAP Funktionsbausteins aus dem E+H Konfigurator 6.0 ... 42

Abbildung 11 - Netzplan zum Projektablauf ................................................................... 51

Abbildung 12 - Validierung der Konfiguration durch SAP Beziehungswissen ................ 53

Abbildung 13 - Technischer Ablauf der Konfiguration ................................................... 55

Abbildung 14 - Neuer Bestellprozess via Online Shop ................................................... 56

Abbildung 15 - Ausschnitt des grafischen Konfigurators des Automobilherstellers Tesla

........................................................................................................................................ 59

Abbildung 16 - Idee des mobilen Endress+Hauser Konfigurators .................................. 60


1

1 Variantenkonfiguration

1.1 Die Komplexitäten

Die Vielfältigkeit von Produkten und deren Fertigung exakt nach Kundenwunsch sollte

in jedem produzierenden Unternehmen gegeben sein. In der folgenden Tabelle ist zu

sehen, dass Produkte nicht nur in verschiedene Modelle eingeteilt werden, sondern

dass von jedem Modell auch noch zahlreiche Modellvarianten existieren und

umgesetzt werden. Das heißt, der Kunde entscheidet sich für ein Modell und hat

anschließend die Möglichkeit aus verschiedensten Modellvarianten auszuwählen.

Diese Vielfalt ist es, die es dem Hersteller ermöglicht individuell auf Kundenwünsche

einzugehen. Allerdings bringt diese Vielfalt auch einige Herausforderungen mit sich.

Beispielsweise fallen Anfertigungen von Spezialteilen an, da die meisten

Modellvarianten nicht auf Lager gehalten sondern In-Time produziert oder eingekauft

werden. Dieses Konzept sorgt für die hohe Priorität der guten Kommunikation

zwischen Vertrieb, Einkauf, Produktion und Logistik.

Modelle Modellvarianten Ø Varianten je Modell

BMW 22 1.295 59

Volkswagen 29 1.255 43

Opel 19 980 52

Audi 45 618 14

Mercedes 28 611 22

Ford 15 558 37

Skoda 11 522 47

Volvo 9 482 54

Seat 12 303 25

Citroen 19 264 14

Tabelle 1: Top 10 Automobilhersteller auf dem deutschen Markt, nach Anzahl der

Modellvarianten1

1 Eigendarstellung nach, (MeinAuto.de & JATO, 2013)


2

Eine weitere Schwierigkeit sind die sich gegenseitig ausschließenden Modellvarianten.

In Bezug auf Tabelle 1 bedeutet dies, dass beispielsweise ein Cabriolet nicht mit einem

Schiebedach kombiniert werden kann. Trotzdem sind ‚Cabriolet‘ und ‚Schiebedach‘

beide Varianten der Kategorie ‚Fahrzeugart‘ bzw. ‚Dach‘.

Wird Beispielhaft der Prozess der Autokäufe im Jahr 2015 analysiert, so fällt auf, dass

der Kunde nur in einen kleinen Teil des Fertigungsprozesses involviert ist und zwar

indem er selbstständig die Konfiguration seines Produktes übernimmt. Dies geschieht

mit Hilfe eines Konfigurators, der meist auf der Website des Verkäufers zur Verfügung

gestellt wird. Hier werden nacheinander Modell und Ausführungen ausgewählt und an

die Kundenwünsche angepasst. Die Auswahl der Modellvarianten liegt hierbei alleine

beim Kunden, der meistens nicht über die sich gegenseitig ausschließenden Varianten

informiert ist. Diese Information sollte daher, genauso wie eventuelle

Lieferverzögerungen bei bestimmen Variantenkombinationen, vom Konfigurator

bereitgestellt und dem Kunden transparent dargestellt werden. Außerdem ist es für

den Kunden hilfreich, sollte die von ihm gewünschte Kombination nicht umsetzbar

sein, wenn der Konfigurator alternative Vorschläge zur Verfügung stellen würde.

Gemäß einer Umfrage auf der Website eines repräsentativen Autohändlers wird die

Möglichkeit zur komplett eigenständigen Konfiguration eines Autos mit 14% als sehr

wichtig eingestuft.2 Hat sich der Kunde nun für eine Konfiguration entschieden, wird

diese dem Autohändler übermittelt. Dieser überprüft nun die Konfiguration und

spezifiziert mit Hilfe eines weiteren Konfigurators die Details, die der Kunde nicht

anlegen konnte.

Als global agierender Anbieter von Messgeräten ist auch Endress+Hauser auch im

Bereich der Konfiguration aktiv. So haben Kunden die Möglichkeit die gewünschten

Produkte vor der Bestellung individuell zu konfigurieren. Dieser Konfigurator, der im

Online Shop verfügbar ist, wird außerdem noch für den Vertrieb und in der Reparatur

eingesetzt.

2 Vgl. (Capgemini, 2010)


3

1.2 Die Herausforderungen

Mit fast 9.000 konfigurierbaren Produkten3 hat Endress+Hauser eine große

Produktpalette. Diese Produkte besitzen insgesamt 75.620 Merkmale4, welchen in der

Summe 449.403 Merkmalswerte zugeordnet sind. Im Durschnitt hat ein Produkt etwa

neun Merkmale mit jeweils sechs Ausführungen. Damit ergeben sich 531.441 mögliche

Kombinationen5 für ein Produkt. Wird diese Zahl aufsummiert, ergeben sich mehr als

vier Milliarden Kombinationsmöglichkeiten6 für alle Endress+Hauser Produkte,

abzüglich der festgelegten Ausschlüsse. Bei den dargestellten Zahlen handelt es sich

um Durchschnittswerte für alle Produkte der Endress+Hauser Gruppe.

Um diese umfangreiche Produktlandschaft zu überblicken hat Endress+Hauser

InfoServe den vorhandenen SAP Konfigurator mit einer Eigenentwicklung abgelöst.

Dabei werden alle Informationen aufgearbeitet und der Kunde hat anschließend die

Möglichkeit, sein gewünschtes Produkt zu bestellen.

Als Datenbasis nutzt der Endress+Hauser Konfigurator die SAP Datenbanktabellen,

welche er durch Webservices erhält. Wird nun ein Ausschluss entdeckt, wird dieser im

Konfigurator als nicht selektierbar gekennzeichnet.

Zum aktuellen Zeitpunkt nutzt der Endress+Hauser Konfigurator Endress+Hauser

eigene SAP Tabellen zur Überprüfung der gewählten Konfiguration. Geplant ist eine

Validierung der im Endress+Hauser Konfigurator gepflegten Konfiguration gegen das

Beziehungswissen, das im SAP gepflegt wurde. Es geht dabei nicht um eine

Nachentwicklung der SAP Logik, sondern ausschließlich um eine Validierung über eine

Schnittstelle zum SAP.

1.3 Das Bestreben

Als IT-Dienstleister für die Endress+Hauser Gruppe hat es sich Endress+Hauser

InfoServe als Ziel gesetzt, eine einheitliche Konfiguration für alle Endress+Hauser

3 Vgl. (Eichkorn, 2015)





4

Produkte zu ermöglichen. Die so erstellten Konfigurationen sollen bereits im SC auf

ihre technische Umsetzbarkeit überprüft werden können.

Um dies zu erreichen, soll in einem ersten Schritt eine Machbarkeitsprüfung

durchgeführt werden, um zu testen, ob das bereits vorhandene Beziehungswissen in

den Endress+Hauser Konfigurator eingebettet werden kann. Anhand eines Beispiels

soll getestet werden, inwiefern eine Kommunikation zwischen Endress+Hauser

Konfigurator und SAP Beziehungswissen möglich ist.

In dieser Arbeit soll geklärt werden, welche Änderungen am momentan verwendeten

Endress+Hauser Konfigurator vorgenommen werden müssen, um ihn an die

gegebenen Bedingungen anzupassen. Im Rahmen dieser Untersuchung wird auch

geklärt werden, mit welchem Aufwand und mit welchen Schwierigkeiten diese

Änderungen verbunden sind und welche Alternativen denkbar wären.

Sollten Aufwand und eventuell auftretende Schwierigkeiten als gering eingeschätzt

werden, so wird der Konfigurator entsprechend den ermittelten Änderungen

angepasst oder ein Modell zu diesen Änderungen erstellt werden.

1.4 Der Ablauf

Nachdem zuerst die Komplexitäten, Herausforderungen und das Bestreben der

Variantenkonfiguration in Zusammenhang mit diesem Projekt erläutert wurden, folgen

nun die Grundlagen, die zum besseren Verständnis der Arbeit beitragen sollen. Diese

Grundlagen beginnen mit einer Übersicht über die Endress+Hauser Gruppe mit ihren

Untereinheiten Product Center, Sales Center und InfoServe, um den Leser darzustellen,

in welchem Umfeld das Projekt erarbeitet wurde. Der Endress+Hauser Konfigurator

6.0, welcher der Gegenstand dieser Arbeit ist, wird nachfolgend beschrieben.

Nun folgen Begriffserläuterungen und Definitionen zum Thema Varianten und

Standard. Diese Begriffe klar festzulegen und einzugrenzen ist unabdingbar für den

weiteren Verlauf der Arbeit, da auf ihnen die Abschnitte Variantenkonfiguration und

Beziehungswissen aufbauen.


5

Um die Grundlagen abzuschließen werden die Methoden, die zur Erstellung der Arbeit

verwendet wurden, aufgezählt und beschrieben. Dazu gehören Experteninterview,

Risikoanalyse, Aufwandsschätzung und Business Process Model and Notation.

Der aktuelle Stand bezüglich des Systems aus Endress+Hauser Konfigurator und SAP

Beziehungswissen wird anschließend in Form der Ist-Analyse dargestellt und analysiert,

um im Anschluss die damit einhergehenden Probleme und das daraus resultierende

Soll-Konzept vorzustellen.

Mit welchen Ansätzen dieses umgesetzt werden kann und welche Vor- und Nachteile

die jeweiligen Ansätze mit sich bringen, wird nun in einer Übersicht dargestellt. Nach

der Auswahl eines Ansatzes wird dieser im Entwicklungsteil der Arbeit theoretisch

umgesetzt und ein Projektplan erstellt.

Das letzte Kapitel fasst die oben genannten Schritte zusammen und zieht Schlüsse, um

dann einen Ausblick zu wagen.

Stammdaten


6

2 Stammdaten

2.1 Endress+Hauser

Die Endress+Hauser Gruppe wurde 1953 gegründet und hat ihren Hauptsitz in

Reinach.7 Die mehr als 12.000 Mitarbeiter verteilen sich auf Standorte in 46 Ländern,

wobei der Umsatz der Gruppe bei etwa 2 Milliarden Euro liegt.8 Heute gehört

Endress+Hauser mit der hohen Vielfalt der verschiedenen Automatisierungslösungen

und Dienstleistungen zu den weltweit führenden Automatisierungsanbietern.9

Unterstützt wird dieses Netzwerk vom Vertrieb, den Sales Centern (SC), und der

Produktion, den Product Center (PC), sowie durch firmeneigene Support Unternehmen

zu denen auch InfoServe gehört.

2.1.1 Endress+Hauser Product Center

In den PCs werden die Endress+Hauser Messgeräte entwickelt und produziert. Dieser

Produktionsverlauf beinhaltet zudem Forschung, Automatisierung und die Trennung

nach den einzelnen Arbeitsgebieten.10

Eines der Endress+Hauser PCs, das PC Wetzer, stellt das Kompetenzzentrum für

Temperaturmesstechnik, Systemkomponenten und Energielösungen dar. Diese und

folgende Informationen nutzen als Quelle die Firmenpräsentation des PC Wetzers.11

Der Fokus in Bezug auf die industrielle Anwendung liegt bei der Lebensmittel-,

Chemie-, Petrochemie-, Grundstoff-, Metall- und Life Science Industrie. Zudem werden

Wasser und Abwasser, Öl und Gas sowie erneuerbare Energien beliefert. Die Produkte

werden exakt nach Kundenwunsch produziert und montiert. Das PC Wetzer zählt 652

Mitarbeiter und Mitarbeiterinnen und wuchs um sieben Prozent im vergangenen Jahr.

7 Vgl. (Endress+Hauser, 2015), S. 28

8 Vgl. (Endress+Hauser Gruppe, 2014)

9 Vgl. (Endress+Hauser, 2015), S. 22

10 Vgl. (Endress+Hauser, 2015)

11 Vgl. (Endress+Hauser Wetzer, 2014), F. 1

Stammdaten


7

Neue Innovationen sind beispielsweise das hygienische Thermometer oder der

Prozessanzeiger. Neben der Herstellung der oben genannten Techniken ist die

Kalibrierung der Geräte ein weiterer Kernprozess des PC Wetzer.

2.1.2 Endress+Hauser Sales Center

In den SCs werden die Endress+Hauser Messgeräte, Dienstleistungen,

Softwareprodukte und Automatisierungslösungen verkauft.12 Um einen ständigen

Austausch zwischen SC und PC zu ermöglichen, sind beide Organisationseinheiten eng

verbunden.13

2.1.3 Endress+Hauser InfoServe

Um die oben beschriebenen Kernprozesse in der Endress+Hauser Gruppe zu

unterstützen, bietet Endress+Hauser InfoServe die entsprechende IT Infrastruktur und

Anwendungslandschaft.14 Die Unterstützung der Geschäftsprozesse in den PCs und SCs

erfolgt über die Wartung und den Ausbau der SAP Struktur, über die Betreuung der

lokalen sowie globalen Netzwerke15, über das Betreiben eines Notfallrechenzentrums

sowie eines Global Helpdesks und über das Bereitstellen von integrierten

Anwendungen und (Backup-)Lösungen.16

Neben der Unterstützung der firmeninternen Prozesse beteiligt sich InfoServe auch an

den IT Lösungen für die Endkunden der Endress+Hauser Gruppe.17

2.2 Der Endress+Hauser Konfigurator 6.0

Wer ein neues Auto kaufen möchte, stellt sich seinen Traumwagen online per

Mausklick zusammen. Genauso funktioniert es mit Endress+Hauser Produkten: Der

Endress+Hauser Konfigurator ermöglicht die kundenspezifische Konfiguration der

Messgeräte. Welche Materialien können für welches Gerät verwendet werden?

Welche Flanschanschlüsse stehen für ein bestimmtes Gerät zur Verfügung? Der

12

Vgl. (Endress+Hauser Messtechnik GmbH, 2015), S. 1 13

Vgl. (Endress+Hauser Messtechnik GmbH, 2015), S. 1 14

Vgl. (Endress+Hauser InfoServe, 2015), S. 1 15



Vgl. (Endress+Hauser InfoServe, 2015), S. 1

Stammdaten


8

Konfigurator gestaltet jedes Produkt genau nach den Bedürfnissen des Kunden.

Gleichzeitig führt das Tool eine Plausibilitätsprüfung durch und stellt damit sicher, dass

Endress+Hauser das konfigurierte Messgerät tatsächlich produzieren kann. Der

Endress+Hauser Konfigurator ist in vielen Prozessen der Firmengruppe im Einsatz, zum

Beispiel im Vertrieb, im Service oder im Marketing. Rund 400.000 Aufrufe gibt es

wöchentlich. Mit dem Update auf die Version 6, in Abbildung 1 zu sehen, wird der

bisher implementierte Endress+Hauser Konfigurator 5.5 für die ganze Gruppe abgelöst.

Die Bedienung des Konfigurators wurde in der neuen Version deutlich vereinfacht. Dies

geschah zum Beispiel durch eine erweiterte Suchfunktion und das Ausblenden nicht

wählbarer Optionen. Auch die hohe Stabilität, eine deutlich bessere Fehlertoleranz aus

Sicht des Nutzers und das neue Design machen das Tool für die Nutzer attraktiv.

Der Konfigurator ist für unterschiedliche Systeme und Prozesse optimiert, damit läuft

er überall reibungslos: im SAP ERP System, Common Equipment Record (CER), SAP

Customer Relationship Management (CRM), SAP Business One (SBO), Online Shop und

Project Engineering Assistant (PEA). Die ebenfalls ganz neu spezifizierte Integration der

technischen Sonderprodukte (TSP) sorgt dafür, dass auch diese vollständig auf

Plausibilität geprüft werden. Bereits 2012 hatte InfoServe gemeinsam mit den

Schlüsselanwendern des Konfigurators damit begonnen die Anforderungen für die

neue Version zusammenzutragen. Im Oktober 2014 starteten Schulungen und Tests in

den Product Centern der Firmengruppe, für die die Einführung inzwischen

abgeschlossen ist. Seit September 2015 ist der neue Endress+Hauser Konfigurator 6.0

flächendeckend im Einsatz.

Stammdaten


9

Abbildung 1 - Endress+Hauser Konfigurator 6.018

Der vereinfachte Ablauf bei einer Konfiguration ist wie folgt: Nach der Auswahl der

spezifischen Konfiguration für das Produkt wechselt der Konfigurator zurück in die

entsprechende Umgebung, aus welcher er aufgerufen wurde zurück. Anschließend

wird dann zum Beispiel der Bestellvorgang fortgesetzt.

2.3 Varianten

2.3.1 Definition des Variantenbegriffs

Wird nach einer Definition für Varianten gesucht, so gibt es verschiedene Quellen, die

unterschiedliche Definitionen liefern. So definiert bereits der Duden die Variante als

eine „leicht veränderte Form von etwas“ und das Deutsche Institut für Normung

beschreibt Varianten als „Gegenstände ähnlicher Form und/oder Funktion mit einem

in der Regel hohen Anteil identischer Gruppen oder Teile“19. Dieser Definition legten

bereits schon Bräutigam20, Kaiser21, Korreck22, Lingnau23 und Menge24 ihre Theorien zu

18

Screenshot des Endress+Hauser Konfigurators 6.0 19

(Deutsches Institut, 2002) , S. 15 20

Vgl. (Bräutigam, 2004), S. 64 21

Vgl. Kaiser, 1995, S. 15 22

Vgl. (Korreck, 2002), S. 9 23

Vgl. (Lingnau, 1994), S. 23

Stammdaten


10

Grunde. Demnach sind Varianten also Objekte, die auf der einen Seite ähnlich

zueinander sind auf der anderen Seite aber mehr oder weniger deutliche Unterschiede

aufweisen können.

Da die oben aufgeführten Definitionen noch unscharf erscheinen, sollen im Folgenden,

der Argumentationslinie von Boysen25 folgend, zwei Leitfragen beantwortet werden,

um im Anschluss eine schlüssige Definition des Variationsbegriffs aufstellen zu können.

Die erste zu klärende Frage ist die nach der Art der Vergleichskriterien. Wodurch

unterscheiden sich die einzelnen Objekte oder Varianten?

Hier werden Merkmale benötigt, welche die Produkte charakterisieren. Wird der

Variantendefinition nach Lingnau gefolgt, so entstehen Varianten bei Ähnlichkeiten in

Bezug auf mindestens eines der Merkmale Geometrie, Material oder Technologie26

oder durch eine verschiedene Anzahl der Teilkomponenten27. Bei näherer Betrachtung

fällt auf, dass diese Merkmale nicht ausreichend sind um alle möglichen Produkte und

Varianten zu beschreiben. So lassen sich verschiedene Lebensmittelvarianten durch

ganz andere Merkmale beschreiben, als beispielsweise Varianten eines Autos. Ein

Aufzählen aller als möglich erscheinenden Produktmerkmale ist wenig sinnvoll,

weshalb je nach Objekt eine Aufzählung von relevanten Merkmalen festgelegt wird.

Welche Merkmale relevant sind wird objektbezogen und subjektiv bewertet.

Die zweite zu bearbeitende Frage befasst sich mit dem Ausmaß der Verschiedenheit.

Wie stark unterscheiden oder ähneln sich die Objekte?

Wird der Anweisung von Gembrys, Heina und Rosenberg vertraut, so findet eine

Feststellung des Verschiedenheitsausmaßes anhand der Ausprägung der einzelnen

Merkmale statt.28 Im Gegensatz dazu stellen Bongulieme, Kohlhase und Rapp29 einen

Bezug zu übergeordneten Eigenschaften her. Diese Eigenschaften werden durch

Merkmale und Ausprägungen beschrieben30, wobei Merkmale nur als solche gezählt

24

Vgl. (Menge, 2001), S. 6 25

Vgl. (Boysen, 2005), S. 11 26

Vgl. (Lingnau, 1994), S.24 27

Vgl. (Deutsches Institut, 2002) , S. 15 28

Vgl. (Gembrys, 1998), S.5; (Heina, 1999), S.5 sowie (Rosenberg, 1996), Sp. 2120 29

Vgl. (Bongulielmi, 2003), S. 65 ; (Rapp, 1999), S. 26 sowie (Kohlhase, 1997), S. 9 30

Vgl. (Rapp, 1999), S. 26

Stammdaten


11

werden, wenn sie eine Unterscheidung der Einheiten ermöglichen. Mit Eigenschaft ist

folglich im weiteren Verlauf dieser Arbeit die Ausprägung eines relevanten Merkmals

gemeint.

Wichtig zu erwähnen in Bezug auf das Ausmaß der Verschiedenheit ist, dass es sich bei

zu großer Ähnlichkeit der Produktvarianten nicht mehr um verschiedene

Produktvarianten innerhalb der gleichen Produktart handelt.31 Eine Produktart erfasst

alle Varianten eines Produkts. Folglich können Produktvarianten nur relativ zu ihrer

Produktart existieren.32

Ein möglicher Definitionsansatz für den Begriff der Variante wäre also der folgende:

Alle Produkte der gleichen Produktvariante weisen die gleiche Ausprägung aller

relevanten Produktmerkmale auf. Verschiedene Produktvarianten bilden

zusammen eine Produktart. Diese Einteilung erfolgt sowohl subjektiv als auch

relativ aus Sicht des Betrachters. Es ist nur dann zweckmäßig von einer Variante

zu sprechen, wenn innerhalb der gleichen Produktart noch mindestens eine

weitere Variante vorhanden ist.

2.3.2 Varianten und Standard

Nach der Definition des Vereins Deutscher Ingenieure (VDI) muss für die Definition

einer Variante eine Grundausführung gegeben sein.33 Diese sogenannte

Grundausführung einer Variante wird im Folgenden als Standard bezeichnet.

Für den Begriff ‚Standard‘ gibt es, wie auch für den Begriff der Variante, verschiedene

Definitionen. So wird der Standard bereits im Duden als „was als mustergültig und

modelhaft angesehen wird und nach dem sich anderes richtet“ beschrieben. Im Gabler

Marketing Lexikon ist ein Standard auf die „durchschnittlichen Erwartungen der

Nachfrager ausgerichtet“.34

Auch hier bedarf es der Klärung einiger Fragen bevor eine Definition für den

Standardbegriff gegeben werden kann.

31

Vgl. (Kohlhase, 1997), S. 20 32

Vgl. (Souren, 1996), S. 87 - 89 33

Vgl. (Verein Deutscher Ingenieure, 1978), S. 179 34

(Bruhn & Homburg, 2004), S. 776

Stammdaten


12

Zunächst müssen die Gründe für Standards erläutert werden. Hier sind zum einen die

historischen Gründe anzuführen. Wenn beispielsweise in einer Firma über lange Zeit

hinweg nur eine Produktvariante innerhalb einer Produktart existierte, so wird diese

Variante als Standard gesetzt und alle weiteren Varianten bleiben normale

Produktvarianten innerhalb der Produktart.

Ein ähnlicher Effekt entsteht durch verschiedene Absatzmengen bzw. Umsätze der

einzelnen Produktvarianten. Häufig wird die Variante als Standard beschrieben, die

eine deutlich größerer Absatzmenge35 oder einen deutlich höheren Umsatz aufweist,

als alle anderen Varianten. Manchmal wird dem Käufer auch zur Vereinfachung der

Verkaufstransaktion ein Standard angeboten auf Grundlage dessen der Kunde seine

Produktvariante festlegen kann. Ein Beispiel ist der Kauf eines Autos, bei dem das

Standardmodell an die Wünsche des Kunden angepasst wird.

Standards entstehen also nicht zufällig, sondern werden von den Unternehmern als

Norm vorgegeben.

Ein weiterer Punkt der in Bezug auf Standards diskutiert werden muss, ist die Relation

zwischen Standard und Variante. Die begriffliche Abhängigkeit wird deutlich, sobald

die Definitionen von Caesar:

„Der Standard stellt den stückzahlstärksten Umfang innerhalb eines

Variantenspektrums dar“36

und Bartuschat:

Varianten als „eine Abweichung vom Standard“37

betrachtet werden. Hier besteht ein klares Abgrenzungsproblem, inwiefern der

Standard, da Teil eines Variantenspektrums, selbst eine Variante ist oder ob Varianten

neben Standards als Abweichungen von ebendiesem existieren. In der Praxis ist es

meist wenig sinnvoll, ein Standardprodukt aus einer Produktart zu identifizieren, da es

meist nicht ausreichend Gründe für eine explizite Unterscheidung zwischen Standard

und Variante gibt. Deshalb wird der Begriff des Standards nicht in die Definition der

35

(Korreck, 2002), S. 57 (Korreck verwendet den Begriff Basisprodukt anstelle von Standard) 36

(Caesar, 1991), S. 160 37

(Bartuschat, 1995), S. 6

Stammdaten


13

Produktvariante aufgenommen sondern lediglich die Möglichkeit genannt ein

Standardprodukt als musterhaften Vertreter innerhalb eines Variantenspektrums zu

identifizieren.

2.4 Variantenkonfiguration

Um das Prinzip der Variantenkonfiguration zu veranschaulichen wird diese im

folgenden Kapitel als untergeordnetes Prinzip der Produktkonfiguration dargestellt. Als

Quelle wird, wenn nicht anders angegeben ‚Variantenkonfiguration mit SAP‘38 von

Uwe Bluhmöhr, Manfred Münch und Marin Ukalovic genutzt. Die Konfiguration

beschränkt sich nicht nur auf Produkte sondern ist in vielen Systemen präsent.

Als Konfigurationsaufgabe wird die Herausforderung eine für den Anwender individuell

passende Einstellung zu finden, indem verschiedene Parameter eingestellt werden,

verstanden. Beispiele für eine solche Konfigurationsaufgabe ist das Schneidern eines

Maßanzugs, der passgenau auf die Wünsche des Kunden zugeschnitten ist oder der

Kauf eines Autos, bei dem sich der Anwender für eine bestimmte Farbe, Ausstattung,

etc. entscheiden muss. Ein stark vereinfachtes Beispiel ist das einer Schachtel, bei dem

verschiedene Farben und Volumen gewählt werden können.

Konfigurationsaufgaben können also in vielen verschiedenen Bereichen vertreten sein.

In manchen Fällen (z.B. Autokauf, Maßanzug oder Schachtel) wird das Produkt nach

den Kundenwünschen spezifiziert und die verschiedenen Parameter werden

angepasst. Bei dieser Produktspezifikation geht es um „die Festlegung aller an ein

Produkt gestellten Anforderungen, also um die das Produkt auszeichnenden

Eigenschaften, die bei dessen Bereitstellung zu beachten sind“.

Die Produkteigenschaften werden beispielsweise in graphischer oder textueller Form

mit den spezifischen Parametern dargestellt. Werden nur einige Parameter angepasst,

während andere gleich bleiben und es sich ansonsten um das gleiche Produkt handelt,

so liegt, wie schon im Kapitel 2.3 erläutert, eine Produktvariante vor.

Wird nun die Konfigurationsaufgabe in Zusammenhang mit der Produktkonfiguration

gebracht, so entsteht daraus die folgende Definition der Produktkonfiguration: Eine

38

(Blumöhr, et al., 2013)

Stammdaten


14

Konfigurationsaufgabe, die sich mit der Spezifikation von Produkten befasst, von

denen verschiedene Varianten existieren.

Bei einer Produktkonfiguration wird meist wie folgt vorgegangen: Nach dem Festlegen

der Parametermenge werden die Parameterwerte definiert. Anschließend werden die

Werte festgelegt, die die individuelle Produkterscheinung charakterisieren.

Soll die Produktkonfiguration automatisiert werden, kommt ein sogenannter

Konfigurator zum Einsatz: Also eine Software, die die Variantenkonfiguration

unterstützt und dabei nach folgenden Arbeitsschritten vorgeht:

Im ersten modellierenden Schritt findet eine formale Festlegung der Parameter statt:

Die Erstellung eines Konfigurationsmodells. Darauf aufbauend findet die aktive

Konfiguration statt, bei der die Parameterwerte entsprechend den

Anwenderwünschen ausgewählt werden. Dieser Schritt der aktiven Konfiguration wird

auch interaktive Konfiguration genannt. Ist der konfigurierende Schritt abgeschlossen,

so startet der dritte und letzte Schritt, bei dem die ausgewählten Werte abgespeichert

und eventuell graphisch dargestellt werden. Das so erhaltene Erscheinungsbild des

Produktes wird als Konfigurationsergebnis bezeichnet.

Abbildung 2 - Prinzipielles Vorgehen bei der Variantenkonfiguration39

Konkret bedeutet dieser Ablauf am Beispiel des oben bereits angeschnittenen

Schachtelbeispiels, dass der modellierende Schritt der ist, bei dem das konfigurierbare

Produkt ‚Schachtel‘ in einer der Farben verfügbar sein soll. Die Werte des Merkmals

Farbe werden als ‚rot‘, ‚gelb‘ oder ‚grün‘ festgelegt. In der aktiven Konfiguration

entscheidet sich der Anwender nun für die Farbe ‚rot‘. Das Ergebnis der Konfiguration

wird nun gespeichert und dem Anwender wird unter Umständen ein Bild der roten

Schachtel präsentiert.

39

(Blumöhr, et al., 2013) S. 37

Stammdaten


15

Das Merkmal, als ein elementarer Konfigurationsbaustein, ist eine wichtige Variable

der Konfigurationsaufgabe. Es beschreibt, dem Schachtelbeispiel folgend, die

Produktoptionen, wie zum Beispiel die Farbe der Schachtel. Der Merkmalswert

beschreibt die Ausprägung des Merkmals, am Beispiel der Schachtelfarbe hat das

Merkmal den Wert ‚rot‘. Als Werte können aber auch Längen-, Gewichts- oder

Materialangaben dienen.

Zwischen einzelnen Merkmalen können Abhängigkeiten auftreten. So hängt das

Schachtelvolumen unter anderem von den Werten der Seitenlängen ab. Diese

Abhängigkeiten werden in den Konfigurationsregeln beschrieben. Ein guter

Konfigurator zeichnet sich durch eine effektive und problemgerechte Formulierung

dieser Regeln aus. Auf Abhängigkeiten wird im folgenden Kapitel dieser Arbeit genauer

eingegangen.

Ein weiterer Teilaspekt der Produktkonfiguration ist der der ‚Mass Customization‘.

Dieser Ausdruck setzt sich aus den englischen Begriffen ‚Mass Production‘ und

‚individual Customization‘ zusammen. Der Begriff soll den enormen Aufwand einer

formalen Modellierung mit der hohen Verbreitung von konfigurierbaren Produkten

rechtfertigen. Durch die ausreichend häufige Lösung einer Konfigurationsaufgabe wird

damit die formale Modellierung lohnend.

Neben diesem Häufigkeitsaspekt spricht oft auch die hohe technische Komplexität

mancher Produkte für die Investition in eine formale Modellierung. Auch wird so die

Automatisierung von betriebswirtschaftlichen Produkten, wie zum Beispiel das

Ermitteln des Verkaufspreises vereinfacht.

Ein System kann strukturell mit der Komponentenstruktur beschrieben werden. Die

Komponenten wiederum können durch eine Aufteilung des Systems in Teilsysteme

strukturiert werden.

Eine Stückliste wirkt hier in Bezug auf die Komponentenstrukturen beschreibend. Die

Stückliste ist wegen ihrer Wichtigkeit in der Produktherstellung ein elementares Ziel

der Produktkonfiguration.

Stammdaten


16

Es existieren zwei Unterklassen der Stückliste. Zum einen die konfigurierbare

Stückliste, die alle denkbaren Komponenten umfasst. Diese wurden zerlegt, weshalb

einige Komponenten nur unter bestimmten Bedingungen Teil der Liste sind.

Eine andere Variante der Stückliste ist die Maximalstückliste, in der alle möglichen

Komponenten aufgeführt und fest ausgeprägt sind. Eine Maximalstückliste der

farbvariierten Schachtel würde neben der Position ‚Schachtel‘ auch alle denkbaren

Farben und die Bedingungen unter welchen sie gewählt werden, enthalten. Wünscht

der Anwender eine Komponente, die nicht auf der Stückliste präsent ist, können zu

einer Maximalstückliste manuell oder automatisiert weitere Komponenten hinzugefügt

werden, wie zum Beispiel die Position ‚rote Schleife‘, die ergänzend auf die Stückliste

geschrieben wird. Die so generierte Stückliste wird als Teil des

Konfigurationsergebnisses gespeichert.

Bei dynamischer Instanziierung handelt es sich um eine alternative zur Stückliste. Es

handelt sich dabei nicht um ein Modell, bei der alle Komponenten im Vorhinein auf

einer Liste festgehalten werden sondern bei dem einzelnen Komponenten in einem

dynamischen Prozess auch noch während der aktiven Konfiguration hinzugefügt

werden können.

Ein sinnvoller Einsatz wäre beispielsweise, wenn bei der Schachtel zusätzlich, an die

äußere Schachtelform angepasste Fächer eingebaut werden sollen. Anstatt vorher alle

Fächer in der Maximalstückliste zu planen, werden die Fächer im Laufe der

Konfiguration passend zur äußeren Schachtelform hinzugefügt.

Der Arbeitsplan legt den Fertigungsablauf des Produktes durch Aufteilung in parallele

oder alternative Arbeitsvorgänge fest. Analog zu den Stücklisten existieren ebenfalls

Maximal- oder konfigurierbare Arbeitspläne.

2.5 Beziehungswissen

Die Informationen über Beziehungswissen, die in diesem Kapitel vorgestellt werden,

basieren auf Uwe Blumöhrs Buch ‚Variantenkonfiguration mit SAP‘40.

40

(Blumöhr, et al., 2013) S. 127 - 150

Stammdaten


17

Allgemeiner Überblick über Beziehungswissen

Das Beziehungswissen hat zwei Aufgaben zu erfüllen. Zum einen die Unterstützung der

Konfiguration der Bewertungsoberfläche, beispielsweise bei einem Kundenauftrag.

Dabei muss das Konfigurationsergebnis vollständig und in sich schlüssig sein. Das

Beziehungswissen wird genutzt, um Bewertungen zu setzen und zu berechnen, sowie

zum Anbieten von Vorschlagswerten. Idealerweise werden verbotene

Bewertungskombinationen in der Oberfläche nicht angeboten.

Der zweite Anwendungsbereich ist die Auflösung von Stücklisten und Arbeitsplänen

entsprechend der Konfiguration. Dabei wird das Beziehungswissen genutzt, um

überflüssige Elemente von Maximalstückliste und -arbeitsplan zu Löschen und

eventuelle Änderungen an den übrigen Elementen vorzunehmen.

Vier Arten von Beziehungen sollen im Folgenden erläutert werden:

‚Vor- und Auswahlbedingungen‘ sowie ‘Prozeduren’ und ‘Constraints’.

Merkmalsabhängigkeiten werden über Vorbedingungen dargestellt. Theoretisch kann

jedes Merkmal jeden der vorher definierten Werte annehmen, unabhängig von den

Werten der anderen Merkmale.

Die Elemente einer Maximalstückliste oder eines Maximalarbeitsplans, die nicht mit

einer Auswahlbedingung gekennzeichnet werden, werden in die aufgelöste Stückliste

bzw. den aufgelösten Arbeitsplan übernommen. Diese Elemente werden Gleichteile

genannt.

Elemente, die mit einer Auswahlbedingung gekennzeichnet sind, werden

Variantenteile genannt. Das Element wird nur dann übernommen, wenn die

Auswahlbedingung erfüllt wird. Auswahlbedingungen können beispielsweise zu

Positionen der Stückliste, Folgenzuordnungen im Arbeitsplan, Fertigungshilfsmitteln im

Arbeitsplan oder Vorgängen im Arbeitsplan zugeordnet sein.

Die Auswahlbedingungen sind auch dann von Bedeutung, wenn ein Merkmal nur unter

gewissen Bedingungen ein Muss-Merkmal und ansonsten ein Kann-Merkmal sein soll.

‘Prozeduren’ bieten eine Möglichkeit zum Festlegen der Merkmalswerte und zum

Lesen von aktuellen Wertsetzungen. Nach dem Konfigurationsstart werden die

Stammdaten


18

‘Prozeduren’ exakt einmal nach einer vorgegebenen Reihenfolge abgearbeitet. Soll ein

Elementdetail geändert werden, so muss es klar der Prozedur zugeordnet sein.

Auch die Bewertung von Merkmalen erfolgt durch ‘Prozeduren’. Hierbei werden

zwischen zwei Herangehensweisen an die Wertsetzung unterschieden.

Die harte Wertsetzung verbietet es Benutzern und ‘Constraints’ Werte zu löschen oder

zu überschreiben. Der einzige Fall, bei dem eine Wertsetzung überschrieben werden

darf, ist wenn eine Prozedur die vorhergehende überschreibt. Der gültige Wert ist

jeweils der, der von der letzten Prozedur gesetzt wurde.

Sogenannte dynamische Vorschlagswerte werden hingegen von der weichen

Wertsetzung zugelassen. Die Werte sind konfigurationsunabhängig und die

Wertsetzung hängt ab von den bereits erfolgten Merkmalsbewertungen.

Eine Prozedur kann dem Konfigurationsmodell, Merkmal oder Merkmalswert

zugeordnet werden. Ersteres ist favorisiert, da daraus eine Kontrolle über die

Abarbeitungsreihenfolge folgt.

Die gleiche Funktionalität wie die ‘Prozeduren’ haben die ‘Constraints’. Sie sind wichtig

in der mehrstufigen Konfiguration da eine Darstellung der Objektabhängigkeiten

ermöglicht wird. Außerdem bieten ‘Constraints’ Auswertungen von Variantentabellen,

-funktionen und Beziehungswissen an und die Einschränkung der

Merkmalswertevorräte.

Bezüglich der Abarbeitungsreihenfolge sind keine Einstellungen erforderlich.

Die verschiedenen ‘Constraints’ werden in sogenannten Constraint- und

Beziehungsnetzen gesammelt, in denen eine Zuordnung ausschließlich nach

Konfigurationsprofil stattfindet. Im Unterschied zu anderen bereits genannten

Bedingungen leisten ‘Constraints’ keinen Beitrag zur Stücklisten- und

Arbeitsplanauflösung.

Stammdaten


19

Einordnung der Beziehungsarten in prozeduales und deklaratives Beziehungswissen

Es existieren drei Arten von Beziehungswissen, die die verschiedenen

Herangehensweisen an den Konfigurator beschreiben.

Das Ergebnis des deklarative Beziehungswissens, zu dem auch ‘Constraints’ und zu

gewissen Teilen ‘Aktionen’ gehören, hängt nur von den Ausgangsbedingungen ab. Der

Zeitpunkt, zu dem die Abarbeitung stattfindet und die Reihenfolge in der dies

geschieht sind dabei nicht relevant. Der Aufbau der Syntax gibt keinerlei Informationen

über die Abarbeitung, allein die Beschreibungen der Bedingungen können aus der

Syntax herausgelesen werden.

Das prozedurale Beziehungswissen arbeitet die ‘Prozeduren’ hingegen zeitabhängig ab.

Eine Zuordnung kann im Vorhinein festgelegt werden. Ein Vorteil des prozeduralen

Beziehungswissens ist die Möglichkeit von sukzessiven Berechnungen und

Vorschlagswertsetzungen.

Semideklaratives Beziehungswissen vereint Eigenschaften von deklarativem und

prozeduralem Beziehungswissen. Die Syntax ist dabei rein deklarativ und macht keine

Vorgaben bezüglich der Abarbeitung. Die Auswertung erfolgt allerdings prozedural und

arbeitet die Vor- und Auswahlbedingungen zeitabhängig ab.

Globaler und lokaler Charakter von Beziehungswissen

Neben der prozeduralen und deklarativen Einteilung des Beziehungswissens, welche

im vorhergehenden Abschnitt erläutert wurde, existiert auch noch die Aufteilung in

lokales und globales Wissen.

Beim lokalen Beziehungswissen erfolgt eine rein numerische, interne

Nummernvergabe. Die ‘Prozeduren’ werden so beispielsweise Prozedur 389, Prozedur

390, Prozedur 391, usw. benannt. Eine Freigabe erfolgt automatisch. Das Anlegen,

Ändern und Löschen der ‘Prozeduren’ wird aus der Zuordnung abgeleitet, welche fest

mit dem Beziehungswissen verknüpft ist. Lokales Beziehungswissen ist nur genau

einmal einsetzbar, und zwar an genau dem Punkt, an dem es erstellt wurde. Im

Gegensatz dazu steht das globale Beziehungswissen, welches wiederverwendbar und

unbegrenzt oft einsetzbar ist. Das globale Beziehungswissen folgt einer nicht-

Stammdaten


20

numerischen, externen Nummernvergabe, sodass die ‘Prozeduren’ beispielsweise

PROZ_AB3, PROZ_3CD, usw. benannt werden. Die Freigabe erfolgt manuell und nicht

automatisch. Statusänderungen beeinflussen die Zuordnung ebenso wenig, wie das

Anlegen von Kurztexten. Für die Pflege ist hier allerdings eine eigene Transaktion von

Nöten. Das Anlegen des globalen Beziehungswissens kann, sofern es sich nicht um

Constraint-Netze handelt, aus der Zuordnung heraus erfolgen.

Aufgrund der besseren Performance durch die Möglichkeit der Mehrfachverwendung

durch Mehrfachzuordnung und aufgrund der deutlich einfacheren Auswertung wird

häufig das globale Beziehungswissen für die Variantenkonfiguration empfohlen.

Der Status des lokalen sowie des globalen Beziehungswissens kann nur dann

‚Freigegeben‘ sein, wenn die Syntax vorhanden und fehlerfrei ist. Liegt eine fehlerhafte

Syntax vor, kann diese zwar gespeichert werden, das Beziehungswissen wird in diesem

Fall allerdings den Status ‚Gesperrt‘ erhalten.

Beziehungswissen bei Variantenkonfiguration und in der Klassifizierung

Sowohl bei der Klassifizierung als auch bei der Variantenkonfiguration kann

Beziehungswissen nutzbringend eingesetzt werden. Bei Ersterem wird das Wissen,

‚Vor- und Auswahlbedingungen‘ sowie ‘Prozeduren’, Merkmalen, Merkmalswerten

oder Klassen zugeordnet. Beziehungswissen, das an Klassen(-knoten) angefügt wird, ist

nur in der Klassifizierung aktiv.

Beziehungswissen und ihre Ausführungsreihenfolge

In der Konfiguration der Bewertungsoberfläche sind alle Arten von Beziehungswissen

nutzbar. Der Zeitpunkt der Abarbeitung kann im Konfigurationsprofil festgelegt

werden. Ein Standardvorgehen ist es, die Abarbeitung nach jedem Bildwechsel und bei

jeder Datenfreigabe, die durch die Entertaste erfolgt, erfolgen zu lassen. Alternative

Einstellungen erlauben eine Abarbeitung auf Anfrage.

Zu Sicherstellung des deklarativen Charakters sind ‘Constraints’ ständig aktiv. Jede

Änderung führt damit zu einer Constraintabarbeitung.

Die Abarbeitung von Beziehungswissen ist fest vorgegeben und findet folgendermaßen

statt:

Stammdaten


21

Im ersten Abarbeitungsschritt werden die Werte, die durch ‘Prozeduren’ gesetzt

wurden, zurückgesetzt. Falls sich dadurch Änderungen an Constraintbedingungen

ergeben, werden nun diese abgearbeitet.

Der nächste Schritt ist die Abarbeitung und einmalige Auswertung der ‘Prozeduren’.

Die Auswertung erfolgt in einer festen Reihenfolge beginnend mit dem

Konfigurationsprofil. Hier wird die Reihenfolge über die sogenannte Sortierung

definiert. Als nächstes werden die Bewertungsmerkmale abgearbeitet. Innerhalb der

Merkmale kann hier zwar eine Reihenfolge vorgegeben werden, die

Abarbeitungsreihenfolge der Merkmale ist allerdings nicht variabel.

Bei der nun folgenden Abarbeitung der Vorbedingungen hat die Reihenfolge keine

Auswirkung auf ‘Prozeduren’ und ‘Constraints’.

Der letzte Schritt, die Abarbeitung der Auswahlbedingungen, hat keine Reihenfolge

und keine Auswirkung auf ‘Prozeduren’ und ‘Constraints’.

Eine Stücklisten- und Arbeitsplanauflösung ist ausschließlich bei Auswahlbedingungen

und ‘Prozeduren’ möglich, wobei die Auswahlbedingungen vor den ‘Prozeduren’

ausgewertet werden.

Die Abarbeitungsreihenfolge unterscheidet sich bei Endress+Hauser grundlegend von

der im SAP, da durch den Einsatz des Endress+Hauser Konfigurator 6.0 dort das

gepflegte Beziehungswissen ausschließlich einmal aufgerufen wird. Allerdings bezieht

der Endress+Hauser Konfigurator kein Beziehungswissen aus dem SAP.

Stammdaten


22

2.6 Methoden

2.6.1 Experteninterview

Das Experteninterview ist zwar als Methode der Organisationsforschung definiert41

bildet hier aber eine Ausnahme, da Methoden in der Regel nicht nach dem Gegenüber

benannt werden, sondern nach dem Verfahren, mit dem Informationen erlangt

werden. Trotzdem ist das Experteninterview, wie auch das leitfadengestützte

Interview, eine Unterklasse des Interviews und kann so verwendet werden.

2.6.2 Risikoanalyse

Unter einem Risiko oder einer Risikosituation wird in der Regel der Eintritt eines

unerwünschten Ereignisses verstanden. Da eine Risikoanalyse meist sehr komplex ist,

wird im Folgenden eine vereinfachte Form aus ‚Risikomanagement für IT-Projekte‘42

erläutert. Ein Ereignis tritt mit einer gewissen Wahrscheinlichkeit ein und verursacht

einen gewissen Schaden. Daher kann das betriebswirtschaftliche Risiko gut durch den

Betriebsschaden beschrieben werden. Um diesen Risikoschaden zu bestimmen müssen

Eintrittswahrscheinlichkeiten und Schadensbetrag herangezogen werden. Innerhalb

von Projekten können unterschiedliche Einzelrisiken auftreten. Der Risikoschaden

für ein Risiko berechnet sich wie folgt:

Dabei steht für den dem Einzelrisiko zugeordneten Schadensbetrag und für die

zugehörige Eintrittswahrscheinlichkeit. Um den für das Projektmanagement relevanten

Gesamtrisikoschaden berechnen zu können, müssen alle Einzelrisikoschäden

aufsummiert werden:

∑

Damit diese Formel zutreffend ist, müssen die Einzelrisiken unabhängig voneinander

sein. Dies kann bei einer Projektorganisation als gegeben betrachtet werden. Für die

Bestimmung von Risikoschäden in der Praxis müssen empirische Methoden zur

41

Vgl. (Kühl, 2009), S. 32 42

Vgl. (Wack, 2006) S. 21 - 27

Stammdaten


23

Bestimmung des Schadenswertes und der Eintrittswahrscheinlichkeit herangezogen

werden. Der Risikoschaden ist dabei entweder eine deterministische Größe, das heißt,

der Wert ist bereits durch Vorbedingungen festgelegt, oder eine stochastische Größe,

wenn der Schaden nur geschätzt werden kann. Auch bei der

Eintrittswahrscheinlichkeit handelt es sich offensichtlich um eine stochastische Größe,

deren Wert nur empirisch, z.B. durch Rückgreifen auf frühere, vergleichbare

Projektdaten oder durch Heranziehen von Experteninterviews, bestimmt werden kann.

Da hier leicht Schätzfehler auftreten können, enthält die so angegebene

Eintrittswahrscheinlichkeit eine stochastische Abweichung von der tatsächlichen

Wahrscheinlichkeit. Um diese Abweichung auszugleichen, können Mittelwerte oder

Streuungen ermittelt werden.

2.6.3 Aufwandsschätzung

In diesem Abschnitt sollen grundlegende Techniken, die ein frühes Abschätzen des

Entwicklungsaufwandes ermöglichen, erläutert werden. Im späteren Projektverlauf

können diese Techniken auch für eine präzisere Schätzung verwendet werden. Das Ziel

ist es, den Gesamtaufwand abzuschätzen, indem das Projekt in seine Teilaktivitäten

zerlegt wird, welche alle Tätigkeiten enthalten, die im Verlauf des Projektes ausgeführt

werden müssen. Neben dieser Kenntnis aller Teilaktivitäten muss auch eine gewisse

Erfahrung vorhanden sein, welche Tätigkeit wie viel Zeit in Anspruch nehmen wird. Da

der schwierigste Teil der Aufwandsschätzung darin besteht, die Arbeit der einzelnen

Teammitglieder zu koordinieren, wird im Folgenden die sogenannte Netzplantechnik

eingeführt.43 Diese Technik beschreibt den Vorgang, bei der zuerst das Projekt in seine

voneinander abhängigen Teilaktivitäten zerlegt wird, um dann für jede Komponente

den Aufwand zu schätzen. Die Summe der Teilaufwände ergibt den Gesamtaufwand.

Eine solche Schätzung ist deshalb genauer als eine Gesamtschätzung, weil der Aufwand

für die Teilaktivitäten statistisch gesehen genauso oft über- wie unterschätzt wird und

somit im Durchschnitt korrekt ist. Sobald alle voneinander abhängigen Teilaktivitäten

ermittelt wurden, werden sie in einem sogenannten Netzplan nebeneinander

angeordnet. Aus diesem Plan kann dann, in Form des sogenannten kritischen Pfades,

43

Vgl. (Mangold, 2009)

Stammdaten


24

die minimale Projektdauer ermittelt werden. Zur Ermittlung der Teilaktivitäten

existieren verschiedene Modelle. Das Wasserfallmodell unterteilt das Projekt in die

folgenden Phasen:

Die Anforderungsanalyse gefolgt von Softwareentwurf, -implementierung und Testen.

Da dieses Modell aber keine ausreichend exakte Unterteilung zur Erstellung des

Netzplans und zur Aufwandsschätzung bietet, wird meist die Work Breakdown

Structure verwendet. Die WBS unterteilt das Projekt zuerst in 25 Teilaktivitäten nach

Jones44 und führt anschließend noch Unteraktivitäten ein, so dass das Projekt am Ende

in ungefähr 50 - 100 Teilaktivitäten unterteilt ist. Charakteristisch für diese Methode

zur Aufwandsschätzung ist also, dass es sich dabei um ein lineares bottom-up Vefahren

handelt, bei dem die Gesamtaufwandsschätzung aus der Aufwandschätzung für die

Teilaktivitäten hervorgeht. Neben dem hier beschriebenen bottom-up Verfahren

existieren auch top-down Methoden, bei denen zuerst der Gesamtaufwand geschätzt

wird um daraus auf den Aufwand für die Teilaktivitäten zu schließen.

2.6.4 Business Process Model and Notation

Nach Heinrich Seidlmeier45 wird der im Folgenden vorgestellte Standard zur

graphischen Darstellung und Modellierung von Prozessen. Die Abkürzung BPMN ist aus

dem Englischen abgeleitet und steht für „Business Process Model and Notation“.

BPMN stellt einen Prozess, ein Fluss oder eine Abfolge von Aktivitäten mit dem Zweck

der Erledigung einer Aufgabe dar. Diese Aktivitäten reichen hierbei vom Arbeitsplatz

bis hin zur Unternehmensebene. Die Darstellung erfolgt über graphische Diagramme,

die aus fest definierten Elementen bestehen. Unterschieden wird zwischen den

sogenannten inner- und überbetrieblichen Prozessen. Erstere werden in der BPMN

Sprache kurz als Prozess bezeichnet und werden über eine zentrale organisatorische

Einheit oder Software gesteuert. Wegen dieser zentralen Steuerung hat sich der Begriff

Orchestrierung etabliert.

Innerbetriebliche Prozesse werden weiterhin in private Prozesse, welche alle

relevanten Daten enthalten, und öffentliche Prozesse, welche nur die auch extern

44

Vgl. (Jones, 2008) 45

Vgl. (Seidlmeier, 2015), S. 159 - 166

Stammdaten


25

einsehbaren Elemente enthalten, gegliedert. Die überbetrieblichen Prozesse

überschreiten, im Vergleich zu den innerbetrieblichen, die Unternehmensgrenzen. Hier

liegt keine zentrale Steuerung vor, vielmehr muss jeder zum Prozess beitragende

Akteur selbstständig wissen, welche Aufgaben zu welchem Zeitpunkt erledigt werden

müssen. Die Koordination erfolgt über Nachrichtenaustausch. Folgend aus dieser

dezentralen Steuerung hat sich die Bezeichnung Choreograph durchgesetzt.

Zur graphischen Darstellung der hier erläuterten Prozesse existieren vier verschiedene

Diagrammtypen, die aus über 100 verschiedenen Elementen des BPMN

zusammengesetzt sind. Die wichtigsten Elemente, unterteilt in fünf Kategorien, sollen

im Folgenden erläutert werden: Flussobjekte definieren das Prozessverhalten. Zu

Flussobjekten zählen Aktivitäten, die der Repräsentation der Prozessschritte dienen. Es

gibt zahlreiche Varianten der Aktivitäten, wie zum Beispiel Task, User Task und Send

Task. Ereignisse, die die Prozesszustände repräsentieren und Gateways, die den

Prozessverlauf über das UND und das ex- und inklusive ODER steuern, zählen ebenfalls

zu den Flussobjekten. Die Kategorie der Daten bzw. Datenobjekte lässt sich mit drei

Elementen nahezu vollständig beschreiben. Hierzu gehören die Dateninput, -output

und -speicherobjekte. Zur Verbindung der Daten- und Flussobjekte dienen die

Verbindungsobjekte.

Durch sie entstehen Sequenzflüsse zur Verknüpfung von Aktivitäten, Nachrichtenflüsse

zum Übermitteln von prozessrelevanten Daten, Assoziationen und Datenassoziationen

zur Verknüpfung von Kommentaren und Artefakten. Die Schwimmbahnen organisieren

die beschriebenen Elemente in Gruppen, die als Pools und Lanes bezeichnet werden.

Diese können sowohl vertikal als auch horizontal angeordnet sein. Ein Pool kann

beispielsweise eine Abteilung repräsentieren, der die alleinige Prozessorganisation

unterliegt, kann aber auch zur Modellierung eines IT-Systems verwendet werden und

dient dem besseren Verständnis des Gesamtprozesses. Die Bahnen unterteilen den

Pool und enthalten den eigentlichen Prozessverlauf. Artefakte konnotieren die Objekte

und sind dabei nicht relevant für den Prozessablauf. Beispiele sind Anmerkungen oder

Gruppierungen.

Stammdaten


26

Zusätzlich zu diesen Basiselementen gibt es noch die erweiterten Elemente, wie zum

Beispiel eine Unterteilung in Start-, Zwischen- und Endereignisse. Diese Elemente

werden in den vier Diagrammtypen, die nun beschrieben werden, verwendet. Das

Geschäftsprozessdiagramm oder auch nur das Prozessdiagramm zeigt

unternehmensinterne Prozesse mit Fokus auf den Arbeitsfluss. Es besteht eine

Ähnlichkeit zu den sogenannten Flussdiagrammen, allerdings bieten die

Prozessdiagramme mehr Ausdrucksmöglichkeiten. Prozessdiagramme benötigen

immer maximal einen Pool. Dagegen haben Choreographiediagramme generell gar

keine Pools. Sie zeigen den Informations- und Nachrichtenaustausch bei

überbetrieblichem Fluss zwischen prozessbeteiligten Partnern an. Der Prozessverlauf

wird mit den oben beschriebenen Prozesselementen dargestellt. Diese beiden

Diagrammtypen werden in Kollaborationsdiagrammen vereinigt, sodass sowohl die

überbetriebliche Zusammenarbeit in Pools und Bahnen dargestellt wird, sowie die

Verbindung der Elemente in benachbarten Polls über den Nachrichtenfluss.

Theoretisch können bei diesem Diagrammtyp einige Pools komplett leer bleiben und

trotzdem verbunden werden. Der vierte Diagrammtyp, der in diesem Kapitel

beschrieben werden soll ist das Konversationsdiagramm, das einen Überblick über den

Nachrichtenaustausch zwischen Geschäftspartnern geben soll. Es gibt keine Auskunft

über die verschiedenen Verarbeitungsschritte. Um eine inhaltliche und strukturelle

Korrektheit sowie die Vollständigkeit und Konsistenz bewerten zu können, gibt es

einige Modellierungsregeln. Die 39 Regeln zur methodischen Korrektheit können in die

folgenden Kategorien eingeteilt werden46:

Sequenzfluss, Start- und Endereignis, angeheftetes Ereignis, sendendes oder

empfangendes Zwischenereignis, Nachrichtenfluss, Gateway und Prozess. Weitere 27

Regeln zur strukturellen Korrektheit betreffen die Bereiche Beschriftungen,

Nachrichtenfluss, Endereignis und das Aufklappen eines Unterprozesses.

46

Vgl. (B, 2012) S. 165

Stammdaten


27

2.6.5 Netzplantechnik

Der Begriff der Netzplantechnik, welcher in diesem Kapitel auf Basis des gleichnamigen

Werks von Dirk Nossten47 erläutert werden soll, beinhaltet viele Modelle, die die

Projektplanung und -umsetzung unterstützen sollen. Die theoretische Grundlage

hierfür ist die aus der Mengenlehre stammende Graphentheorie, die eine Menge von

Kanten und Knoten in Form eines Knotengraphen untersucht. Ein Beispiel hierfür ist

die nachfolgende Abbildung.

Abbildung 3 – Beispiel für einen gerichteten, endlichen und kreisfreien Graphen48

Welche Form für die Knoten gewählt wird ist dabei nicht relevant. Bei einem

Knotengraph verbinden Kanten in Form von Pfeilen zwei Knoten miteinander. Jeder

Knoten ist durch mindestens eine Kante mit einem anderen verbunden. Jeder Kante ist

ein Wert zugeordnet.

Durch diese Kanten und Knoten können alle Vorgänge, Ereignisse und

Anordnungsbeziehungen innerhalb eines Projektes dargestellt werden. Vorgänge

beanspruchen dabei Zeit, Ereignisse kennzeichnen bestimmte Zeitpunkte und

Anordnungsbeziehungen legen die Abhängigkeiten und Reihenfolgen zwischen den

Vorgängen und Ereignissen fest.

In dieser Arbeit werden die sogenannten vorgangsorientierten Knotennetzpläne

verwendet, bei denen Ereignisse vernachlässigt werden und Vorgänge als Knoten

dargestellt werden. Ein Beispiel für einen solchen Netzplan kann Abbildung 11

herangezogen werden.

Die Anordnungsbeziehungen zwischen den verschiedenen Vorgängen werden durch

Pfeile dargestellt. So können verschiedenste Abhängigkeiten dargestellt werden.

Beispielsweise, wenn die abgeschlossene Ausführung eines Vorganges Bedingung für

47

Vgl. (Noosten, 2013) 48

(Noosten, 2013) Abb.2.1

Stammdaten


28

mehrere nachfolgende Vorgänge ist oder mehrere Vorgänge Bedingung für einen

einzigen nachfolgenden Vorgang.

Es wird zwischen vier Möglichkeiten für Abhängigkeiten zwischen Vorgängen

unterschieden. Die Normalfolge, die auch als „Ende-Anfang“-Beziehung bezeichnet

werden kann, beschreibt den Fall, in dem das Beenden eines Vorganges Bedingung für

den Anfang des nachfolgenden Vorgangs ist. Im Graph geht dementsprechend der Pfeil

vom Vorgangsende zum Vorgangsanfang. Analog gibt es ebenfalls „Anfang-Anfang“-,

„Ende-Ende“- und „Anfang-Ende“-Beziehungen.

Ein Minimalabstand zwischen zwei Vorgängen ist die Zeitspanne, die mindestens

eingehalten werden sollte. Sie darf überschritten werden. Dahingegen darf die Zeit des

Maximalabstandes zwischen zwei Vorgängen nicht überschritten werden.

Um die verschiedenen Zeitpunkte zu berechnen gibt es Rechenregeln, abhängig von

der Art der Anordnungsbeziehungen. Im Folgenden werden die Methoden zur

Zeitpunktsberechnung für Normalfolgen erläutert.

Der erste Schritt ist es dabei die Dauer der Vorgänge in die Knoten zu schreiben und

die Abstände an die Pfeile.

Bei der Vorwärtsrechnung wird nun beginnend beim Startvorgang jeweils der frühste

mögliche Anfangs- und Endzeitpunkt berechnet. Dabei gilt:

. steht dabei für den frühesten möglichen Anfangszeitpunkt, für den

frühesten möglichen Endzeitpunkt und für den minimalen Zeitabstand zwischen

beiden Vorgängen. Bei mehreren Vorgängen wird mit der jeweils höchsten Summe

gerechnet.

Die Rückwärtsrechnung geht von dem bereits berechneten Endzeitpunkt des

Zielvorganges, also des letzten Vorganges, aus. Davon ausgehend werden durch

Subtraktion nun die spätesten möglichen Anfangs- (SAZ) und Endzeitpunkte (SEZ)

berechnet. Bei mehreren Vorgängen gilt die niedrigste Differenz.

Kritische Vorgänge sind diese, bei denen FAZ und SAZ zusammenfallen. Solche

Vorgänge liegen auf dem kritischen Weg durch den Netzplan. Alle Vorgänge, die nicht

Stammdaten


29

auf diesem Weg liegen haben eine Pufferzeit. Die Gesamtpufferzeit wird wie folgt

berechnet:

.

Ist im Netzplan ein Maximalabstand angegeben, so wird dieser bei der Berechnung

zunächst vernachlässigt und erst nach Abschluss der Berechnung wird geprüft, ob für

die Maximalabstände die möglichen Zeitpunkte für Vorgänger und Nachfolger im

Widerspruch stehen.

Für eine genauere Berechnung der Pufferzeiten muss zunächst zwischen drei für diese

Arbeit relevanten Pufferzeiten unterschieden werden: die Gesamtpufferzeit , die

freie Pufferzeit und die unabhängige Pufferzeit .

Erstere beschreibt die Zeitspanne zwischen frühestem und spätestem Endzeitpunkt

und wird, wie bereits erwähnt folgendermaßen berechnet:

.

Die freie Pufferzeit beschreibt die Zeitspanne, um die ein Vorgang von seinem FAZ

verschoben werden kann, ohne, dass Einfluss auf den FAZ des Nachfolgers genommen

wird. Für Normalfolgen gilt:

Für Vorgänge in der Reihenfolge dann dann .

Die Zeitspanne, um die ein Vorgang verschoben werden kann, wenn alle Vorgänger

zum spätesten Zeitpunkt starten und alle Nachfolger zum frühesten, wird unabhängige

Pufferzeit genannt. Dabei gilt: .

Um die Zeitpunkte FAZ und SAZ zu berechnen können die folgenden Formeln

herangezogen werden:

und

Die Dauer des Vorgangs ist in enthalten.

Der Wandel


30

3 Der Wandel

3.1 Vergangenheit der Zukunft

Als IT-Dienstleister für die Endress+Hauser Gruppe, ist es die Aufgabe von

Endress+Hauser InfoServe die Systeme, die für den Produkt Lifecycle Prozess relevant

sind, hoch verfügbar und performant zur Verfügung zu stellen. Dabei ist durch die

Jahre des Bestehens eine Struktur entstanden, die für den Bestell- und

Produktionsprozess sehr ausschlaggebend ist. So gibt es für einen örtlichen

Zusammenschluss von SCs, zum Beispiel alle SCs aus Europa oder alle SCs aus Afrika,

eine SAP Installation. Des Weiteren hat jedes PC eine eigene SAP Umgebung, in

welcher es seine Produkte anlegen und die Produktion organisieren kann. Dies hat den

großen Vorteil, dass zum Beispiel Updates am System immer in der entsprechenden

Nacht durchgeführt werden können, da durch die geographische Trennung die

Arbeitszeiten variieren und so keine Produktions- oder Verkaufsprozesse gestört

werden.

In Bezug auf die Konfiguration von Produkten übernehmen die SCs eine übergeordnete

Rolle, indem sie auf Produktebene konfigurieren. Sie betrachten dabei die für den

Kunden relevanten Bauteile und Ausführungen und senden die Bestellung nach

Abschluss in das SAP System des PCs, welches das Produkt produziert. Im PC werden

aus der Konfiguration des SCs weitere Merkmale, die für die Produktion relevant sind,

abgeleitet. Dies geschieht über SAP Beziehungswissen auf Konfigurationsprofil- oder

Merkmalsebene.

In Abbildung 8 ist der gesamte Bestellprozess an einem Beispiel dargestellt. Es handelt

sich dabei um einen Kunden, der über den Online Shop ein neues Produkt bestellen

möchte. Er besucht nun also den Online Shop und wählt die gewünschten

Basisprodukte und die entsprechende Menge aus. Anschließend wird er automatisch

zum Endress+Hauser Konfigurator 6.0 weiter geleitet, in welchem er die Konfiguration

seiner ausgewählten Produkte vornimmt.

Der Wandel


31

Mit dem Start des Endress+Hauser Konfigurator 6.0 werden alle benötigten

Informationen über das Produkt und seine Abhängigkeiten geladen. Im Folgenden ist

auf fünf Abbildungen zu sehen, wie die Konfiguration voran schreitet.

In der nachfolgenden Abbildung ist der Ausgangsstatus des zu konfigurierenden

Produkts zu sehen. Auf der linken Seite sind die Merkmale zu sehen, welche

konfiguriert werden müssen. Durch die rote Markierung am linken Bildrand ist

ersichtlich, dass dieses Merkmal noch nicht konfiguriert wurde, was aber noch vor dem

Absenden geschehen muss. In der rechten Spalte sind die auswählbaren

Merkmalswerte zu sehen. Die grau ausgebleichten Optionen sind ausgeschlossene

oder deaktivierte Merkmalswerte. Mit der Auswahl eines validen Merkmalwertes

springt der Konfigurator direkt in die Auswahl für das nächste Merkmal.

Abbildung 4 - Ausgangsstatus einer Produktkonfiguration49

In der nächsten Abbildung ist eine weiter fortgeschrittene Konfiguration zu sehen. Die

bereits spezifizierten Merkmale werden grün hinterlegt und der Merkmalswert wird

unter dem Namen des Merkmals sichtbar. Im Fall des aktuell ausgewählten Merkmals

wurde eine frei spezifizierbarer Merkmalswert ausgewählt und der Wert ‚500‘

49

Screenshot des Endress+Hauser Konfigurators 6.0

Der Wandel


32

eingetragen. Dies ist ein valider Wert, da er innerhalb des Bereichs ‚110‘ bis ‚4000‘

liegt.

Abbildung 5 - Spezifizierung von frei wählbaren Merkmalswerten50

Fällt dem Kunden bei der Spezifizierung eines Merkmals ein, dass er ein grau

hinterlegtes, also ausgeschlossenes Merkmal wählen möchte, wird ihm angezeigt,

welche anderen Merkmale die Wahl dieses Merkmalswertes verhindern. Er hat somit

die Möglichkeit, in der Konfiguration ein für ihn optimales Gerät zu konfigurieren.

50


Der Wandel


33

Abbildung 6 - Fehlerhafte Konfiguration51

In der nachstehenden Abbildung ist die vollständige Konfiguration zu sehen, welche

nun durch das Betätigen des ‚Übernehmen‘ Knopfes zurück an das entsprechende

System gesendet wird.

Abbildung 7 - Vollständige Konfiguration52

51


Der Wandel


34

Ist dies geschehen, sendet der Kunde die Bestellung ab und erstellt somit eine

Bestellung im SAP System des für ihn relevanten SCs. Das SC überprüft die Bestellung

auf mögliche Fehler bei der Übertragung und fügt, für diese Arbeit eher

nebensächliche, Bestandteile, wie zum Beispiel Konditionen, zu dem Auftrag hinzu. Ist

dies geschehen, wird ein Produktionsauftrag im PC, welches dieses Produkt produziert,

erstellt.

Das PC leitet nun mit Hilfe des Beziehungswissens, das in ihrem SAP System hinterlegt

ist, die endgültige Konfiguration für ihre Produktion ab. Dadurch werden die

Arbeitspläne und Stücklisten auf die Bestellung angepasst. Bevor das Produkt in die

Produktion geht, wird es von Mitarbeitern des PCs auf die technische Umsetzbarkeit

überprüft. Wird eine Einschränkung festgestellt, wird diese dem Kunden mitgeteilt und

die nötigen Änderungen an seiner Konfiguration werden ihm erklärt. Sobald sich der

Kunde für eine umsetzbare Konfiguration entschieden hat, kann die Produktion

beginnen. Der Prozess wird mit der Fertigstellung des Produkts beendet.

52


Der Wandel


35

Abbildung 8 - Bestellprozess via Online Shop53

53

Eigendarstellung nach (Eichkorn, 2015)

Der Wandel


36

Der in Abbildung 8 dargestellte Prozess bedarf manueller Eingriffe, wie zum Beispiel für

die Validierung der Konfiguration der Produkte. Dort werden, von dem für das Produkt

verantwortliche PC, die Ausschlüsse mithilfe Transaktion im SAP gepflegt. Auf diese

Ausschlüsse kann der Endress+Hauser Konfigurator 6.0 zugreifen und somit

ausschließlich valide Konfigurationen zulassen. Einige Ausschlüsse lassen sich in dieser

Transaktion allerdings nicht umsetzen, was die bereits erwähnte Prüfung der

technischen Umsetzbarkeit nötig macht. Wird zum Beispiel bei einer Konfiguration

eine frei wählbare Länge für einen Temperatursensor gewählt, ist diese vom PC

manuell zu validieren. Dabei müssen die Mitarbeiter manuell berechnen, ob zum

Beispiel eine maximale Länge für ein bestimmtes Bauteil überschritten wurde.

Zusätzlich zum Online Shop gibt es einige weitere Möglichkeiten, wie ein Kunde von

Endress+Hauser ein Produkt bestellen und anschließend konfigurieren kann. Eine

davon ist der Offline Konfigurator, welcher einmal im Jahr von den Sales Centern an

die Kunden verschickt wird. Es handelt sich dabei um eine DVD mit den aktuellen

Produkten, die dazugehörigen wichtigen Informationen, Ausschlüsse und einem

Berechnungstool, das es ermöglicht, die variablen Längen im oben beschriebenen

Problem zu berechnen und somit zu validieren. Nach der Konfiguration exportiert der

Kunde eine XML Datei und lädt diese im Online Shop hoch und kann anschließend die

Bestellung wie gewohnt durchführen.

3.2 Optimierungspotenzial

Der im vorherigen Kapitel dargestellte Prozess hat einige Möglichkeiten zur

Optimierung. Eines der größten Probleme ist, dass der Kunde während der

Konfiguration seines Produkts im Endress+Hauser Konfigurator 6.0 angeblich weiß,

dass seine Konfiguration valide ist, aber es kann passieren, dass nach der Bestellung

das Product Center darüber informieren muss, dass die Konfiguration doch nicht

umsetzbar ist. Der Grund dafür ist, dass im Endress+Hauser Konfigurator 6.0 keine

Möglichkeit besteht, Werte miteinander zu verrechnen und somit neue

Abhängigkeiten zwischen Werten von freien Merkmalsfeldern zu definieren.

Der Wandel


37

Ein weiteres Problem ist der hohe Zeitaufwand für das PC, falls es zu einem Problem

bei der Validierung kommt. Die Konfiguration der Produkte kann bei einigen Kunden

oft bis zu mehreren Wochen dauern. Eine unerwartete Änderung kann den kompletten

Prozess erneut anstoßen, was wiederum zum Stillstand der Produktion für die gesamte

Bestellung führt. Somit kann ein vereinbarter Liefertermin womöglich nicht mehr

eingehalten werden.

3.3 Zukunft der Vergangenheit

Im Gespräch mit den Produktmanagern des PC Wetzers54, welches nachfolgend

beispielhaft für alle PCs der Endress+Hauser Gruppe steht, und den Verantwortlichen

des Endress+Hauser Konfigurators 6.055 hat sich ergeben, dass dem Kunden in Zukunft

direkt bei der Konfiguration mitgeteilt werden soll, falls er eine Konfiguration gewählt

hat, die so im PC nicht umsetzbar ist. Mit Hilfe des SAP Beziehungswissens, welches

das PC für seine Produkte pflegt, ist es möglich, den Prozess der Validierung, welcher

zum aktuellen Zeitpunkt erst kurz vor der Produktion stattfindet, bereits vor Abschluss

der Konfiguration durchzuführen. Dies ist möglich, da im SAP Beziehungswissen das

Rechnen mit Variablen möglich ist und da das PC das entsprechende Knowhow hat, um

die dafür benötigten Formeln zu erstellen.

Die Problematik der Längenberechnung ist hierbei nur beispielhaft zu sehen, genauso

wäre es möglich eine frei auswählbare Kalibrierungstemperatur von den Materialien

abhängig zu machen.

Im Gespräch56 wurde ebenso definiert, dass bei gleichwertigen Ansätzen derjenige,

welcher das geringste Risiko und alles in allem wirtschaftlich am sinnvollsten ist,

umgesetzt werden soll.

54

Vgl. (Diemer, 2015) 55

Vgl. (Lauke, 2015) 56

Vgl. (Lauke, 2015)

Evaluation


38

4 Evaluation

4.1 Allgemeines

Um den eigentlichen Grund für dieses Projekt noch einmal in Erinnerung zu rufen, wird

nachfolgend ein anschauliches Beispiel beschrieben.

Wird vom Kunden zum Beispiel ein Endress+Hauser Temperaturmessgerät wie in der

nachfolgenden Abbildung bestellt, bei welchem ein frei spezifizierbarer Merkmalswert

für das Merkmal ‚Länge des Halsrohr‘ gewählt wurde, kann der Fall eintreten, dass das

Messgerät für den Kunden trotz valider Konfiguration nicht einsatzfähig ist. Der Grund

für diese Nicht-Einsetzbarkeit kann in diesem Fall beispielsweise die zu hohe

Temperatur des zu messenden Mediums sein. Da das Medium einen Wärmgradient in

seiner Umgebung verursacht, kann bei zu kurzer Halsrohrlänge die Temperatur um das

Gehäuse herum für die enthaltene Elektronik zu hoch sein. In diesem Fall muss der

Kunde einen höheren Wert für die Sensorlänge eingeben.

Evaluation


39

Abbildung 9 - Omnigrad M TR1057

57

Endress+Hauser Mitarbeiter Portal Engine

Prozessanschluss

Halsrohr

Schutzrohr

Anschlusskopf

Gehäuse

Evaluation


40

Dieses Wissen ist allerdings nicht im Konfigurator verfügbar, da die dafür nötigen

Berechnungen nicht abbildbar sind. Dort ist es ausschließlich möglich in einer Tabelle

mögliche Kombinationen von Merkmalswerten zu hinterlegen, welche anschließend im

Konfigurator genutzt werden, um die Konfiguration zu validieren. Dabei ist es nicht

möglich Merkmalswerte miteinander zu verrechnen und daraus Ausschlüsse

abzuleiten.

Im Folgenden werden vier Ansätze zur Integration von SAP Beziehungswissen in den

Endress+Hauser Konfigurator 6.0 dargestellt und deren Aufwand anhand von

Erfahrungswerten abgeschätzt. Abschließend wird anhand der nachfolgenden

Kriterien58 eine Entscheidung getroffen, welcher der Ansätze umgesetzt werden soll.

Die detaillierte technische Umsetzung wird im nächsten Kapitel beschrieben.

Die wichtigste Anforderung ist, dass in einem Projekt, mit definiertem Anfangs- und

Endtermin, eine Lösung entwickelt wird, welche das vom PC hinterlegte

Beziehungswissen im SAP System zur Validierung von Konfigurationen im

Endress+Hauser Konfigurator 6.0 nutzen zu können.

4.2 Ansätze

4.2.1 Ansatz Eins

Als erster Ansatz wird die Beauftragung eines externen Dienstleisters in Betracht

gezogen. Beim Kontaktieren von mehreren, für SAP Erweiterungen bekannten

Entwicklerhäusern, wurde schnell klar, dass es sich bei der Nutzung von SAP

Beziehungswissen in einem externen Konfigurator um eine Anforderung handelt, mit

der noch niemand Erfahrungen gesammelt hat. Nach den thematischen Gesprächen

mit mehreren Entwicklungshäusern konnte niemand die Anforderungen aus dem

vorherigen Kapitel erfüllen. Zusätzlich wurde angezweifelt, ob die Beauftragung einer

externen Firma aus wirtschaftlicher Sicht sinnvoll ist, da Endress+Hauser InfoServe

theoretisch die Möglichkeiten hätte, das Projekt umzusetzen.59

58

Vgl. (Lauke, 2015) 59

Vgl. (Lauke, 2015)

Evaluation


41

4.2.2 Ansatz Zwei

Als zweiter Ansatz soll der Versuch, das SAP Beziehungswissen nach zu entwickeln,

dargestellt werden. Auch wenn dieser Ansatz bereits im Kapitel, das die Zielsetzung der

Arbeit behandelt, ausgeschlossen wurde, wird er an dieser Stelle der Vollständigkeit

halber kurz erläutert.

Das SAP Beziehungswissen, welches die PCs pflegen können, hat die Möglichkeit hoch

komplexe Rechnungen und Gleichungssysteme zu lösen und daraus mögliche

Kombinationen für Konfigurationen auszuschließen oder zu verändern.

Zum aktuellen Zeitpunkt ist dies im Endress+Hauser Konfigurator 6.0 nicht möglich.

Dort ist es ausschließlich möglich in einer Tabelle mögliche Kombinationen von

Merkmalswerten zu hinterlegen, welche anschließend im Konfigurator genutzt

werden, um die Konfiguration zu validieren.

Das Abbilden von komplexen Gleichungen ist in dieser Tabelle nicht möglich. Daher

wäre es nötig, die Gleichungen und Rechnungen in einem SAP Funktionsbaustein,

welcher aus dem Konfigurator aufgerufen werden kann, zu entwickeln. Wie in der

nachfolgenden Abbildung zu sehen ist, wird aus dem Endress+Hauser Konfigurator in

diesem Fall ein Webservice aufgerufen, welcher das Ergebnis der in dem

Funktionsbaustein abgelaufenen Berechnung zurückgibt.

Evaluation


42

Abbildung 10 - Aufruf eines SAP Funktionsbausteins aus dem E+H Konfigurator 6.060

Das Wissen ist in diesem Modell doppelt vorhanden, nämlich im SAP Beziehungswissen

und im SAP Funktionsbaustein.

4.2.3 Ansatz Drei

Der dritte Ansatz basiert darauf, das SAP Beziehungswissen, welches bereits von den

PCs gepflegt wurde, per Webservice aus dem Endress+Hauser Konfigurator 6.0 zu

validieren.

60

Eigendarstellung

Evaluation


43

4.2.4 Ansatz Vier

Der vierte Ansatz basiert auf der gleichen Idee wie Ansatz drei, allerdings wird in

diesem Fall ein schon seit langer Zeit integrierter externer Mitarbeiter von

Endress+Hauser InfoServe mit einbezogen, welcher die Entwicklung an ausgewählten

Stellen unterstützen soll.

4.3 Aufwandsschätzung

4.3.1 Ansatz Eins

An dieser Stelle ist keine Aufwandsschätzung für Ansatz eins möglich, da keiner der

kontaktierten Dienstleister eine fertig entwickelte Lösung für die Integration von SAP

Beziehungswissen in den Endress+Hauser Konfigurator 6.0 gefunden wurde.

Sobald sich eine neue Möglichkeit bietet, ist geplant, diese zu evaluieren.

4.3.2 Ansatz Zwei

Der für den zweiten Ansatz benötigte Aufwand ist ein Wiederkehrender, da mit jedem

neuen Produkt der PCs womöglich auch Bedarf für einen neuen Webservice und für

einen neuen SAP Funktionsbaustein besteht. Zusätzlich muss es eine Pflegemaske

geben, in welcher hinterlegt werden kann, welcher Webservice zu welchem Produkt

und Merkmalswert gehört.

Wird von einem Aufwand von zwei Personentagen für die Weiterentwicklung des

Webservices, der Neuentwicklung des SAP Funktionsbausteins und der Eintragung in

die Pflegetabelle ausgegangen, bedarf es bei circa einem neuen Produkt im Jahr61 zwei

Personentagen. Vernachlässigt wird in dieser Rechnung der einmalige Aufwand von

zwei Personentagen, welche nötig wären um die Pflegemaske und die entsprechende

Tabelle für die Zuordnung der Produkte, Merkmale und Merkmalswerte zum

jeweiligen Webservice zu speichern. Wird dies mit einem Stundensatz von 100€

verrechnet, werden jährliche Kosten von 200€ benötigt um bereits gepflegtes Wissen

erneut zu entwickeln und zur Verfügung zu stellen.

61

Vgl. (Diemer, 2015)

Evaluation


44

4.3.3 Ansatz Drei

In der Tabelle 2 eine Übersicht über die Berechnung zu sehen, welche für diesen

Ansatz genutzt wurde. Für den dritten Ansatz ist die Annahme, dass für die Vorarbeit,

das heißt die genaue technische Überprüfung und Analyse der Machbarkeit, circa 40

Stunden von einem InfoServe Mitarbeiter beansprucht werden. Des Weiteren werden

für die detaillierte Modellierung des Prozesses vier Personen von InfoServe, eine

Person vom PC Wetzer und eine Person vom SC Deutschland für circa acht Stunden

benötigt.

Um das Beziehungswissen im Endress+Hauser Konfigurator einsetzen zu können, muss

es zuvor im SAP eingepflegt werden. Meist ist dies schon der Fall, es wird also hier

davon ausgegangen, dass nur circa zehn neue Produkte eingepflegt werden müssen.

Für jedes Produkt werden, abhängig von der Art des Produktes, etwa zwei Stunden

benötigt. Für den Endress+Hauser Konfigurator ist es wichtig zu wissen, ob das aktuell

behandelte Produkt durch SAP Beziehungswissen validiert werden muss. Um dies zu

gewährleisten, muss eine Pflegeoberfläche zur Verfügung gestellt werden, was alles in

allem 12 Stunden Arbeit für InfoServe bedeutet.

Nach der Pflege ist es anschließend nötig die Daten aus der zentralen Datenbank in alle

SAP Systeme zu verteilen, damit diese in allen SAP Systemen konsistent sind. Für

diesen Vorgang werden vier Stunden benötigt.

Ebenso muss das PC Wetzer die zehn neuen Produkte einpflegen, was je Produkt zehn

Minuten Aufwand bedeutet. Zusätzlich zur Pflege muss auch ein Webservice

programmiert werden, der überprüft, ob eine Validierung über das SAP

Beziehungswissen nötig ist. Dafür werden weitere 12 Stunden Aufwand für InfoServe

geschätzt.

Der nächste Schritt ist die Anpassung der Benutzeroberfläche im Endress+Hauser

Konfigurator. Dort arbeitet Endress+Hauser InfoServe schon lange mit einem externen

Partner zusammen, der für diese Arbeit circa 12 Stunden Arbeit benötigt. Das

InfoServe Team benötigt dafür weitere sechs Stunden. An dieser Stelle besteht Bedarf

für einen Webservice zum Aufrufen des Beziehungswissens. Dieser soll überprüfen, ob

die jeweilige Konfiguration valide ist und im PC produziert werden kann.

Evaluation


45

Die Implementierung des Webservices bedeutet 24 Stunden Aufwand für InfoServe.

Zum Abschluss muss die Applikation und ihre Neuerungen getestet werden. Dabei sind

40 Stunden für InfoServe, 32 Stunden für das PC Wetzer und 12 Stunden für das SC

Deutschland vorgesehen. Alles in allem wird noch ein Aufwand für die Projektplanung

und -steuerung eingeplant. In diesem Fall wird mit einem Aufwand von zehn Prozent

des Gesamtaufwands gerechnet. Dies entspricht circa 28 Stunden Aufwand, den

InfoServe als Leiter des Projektes tragen muss. Zusammen ist somit ein Aufwand von

circa 38 Personentagen nötig, um das Projekt umzusetzen.

Tabelle 2 - Aufwandsberechnung Ansatz 3

Um ein Projekt in dieser Größenordnung umzusetzen, bedarf es zusätzlich einer

Risikoanalyse, die anschließend eine mögliche Abweichung von dem in der Schätzung

eingeplanten Aufwand angibt. In der nachfolgenden Tabelle ist die Berechnung für die

Risiken ersichtlich, eine Erläuterung erfolgt anschließend.

Beschreibung Faktor IS Fatkor PC Faktor SC Faktor OIO Aufwand Summe IS Summe PC Summe SC Summe OIO Gesamt

Vorarbeit 1,00 40 40 0 0 0 40

Modellierung Prozess 4,00 1,00 1,00 8 32 8 8 0 48

Pflege Beziehungswissen 10,00 2 0 20 0 0 20

Pflegeoberfläche ob Bezw da 1,00 12 12 0 0 0 12

Pflege Tabelle ob Bezw da 10,00 0 0 2 0 0 2

Webserve ob Bezw da 1,00 12 12 0 0 0 12

Verteilung 1,00 4 4 0 0 0 4

Anpassung UI 1,00 2,00 6 6 0 0 12 18

Webservice Bezw 1,00 24 24 0 0 0 24

Testing 3,33 2,67 1,00 12 40 32 12 0 84

Doku überarbeiten 1,00 16 16 0 0 0 16

Projektmanagement (10%) 28 28

Stunden 214 62 20 12 308

Tage 27 8 3 2 38

Stundensatz 100,00 € 100,00 € 100,00 € 100,00 € Betrag 21.396,67 € 6.166,67 € 2.000,00 € 1.200,00 € 30.763,33 €

Evaluation


46

Tabelle 3 - Risikobewertung Ansatz 3

Ein Risiko ist, das die Vorarbeit des InfoServe Mitarbeiters nicht zu dem gewünschten

Erfolg kommt, und daher nach den 40 Stunden keinerlei Grundlage vorhanden ist, auf

der das eigentliche Projekt aufbauen kann. Die Auswirkung wäre der Abbruch des

Projekts oder eine weitere Investition von Zeit, um die Vorarbeit zufriedenstellend

abzuschließen. Die Eintrittswahrscheinlichkeit des Risikos, weitere 20 Stunden für

diese Tätigkeit zu beanspruchen, liegt bei 20%. Somit liegt der Risikoschaden für dieses

Einzelrisiko bei vier Stunden. Bei weiterer Betrachtung der Arbeitsschritte ist ein

weiteres Risiko bei der Modellierung des Prozesses zu erkennen. Dabei sind drei

unterschiedliche Parteien beteiligt, die alle ihre Meinung vertreten. Die

Eintrittswahrscheinlichkeit, dass weitere 8 Stunden pro Person nötig sein werden liegt

dabei bei 30%. Der Risikoschaden liegt somit bei 14,4 Stunden.

Bei allen Entwicklungsaufgaben gibt es das Risiko, dass die Umsetzung in der geplanten

Form nicht möglich ist. Daher ist die Eintrittswahrscheinlichkeit, dass weitere zehn

Prozent der bereits aufgewendeten Zeit zusätzlich benötigt werden, bei 25%. In der

Summe werden somit 2,2 Stunden Risikoschaden berücksichtigt. Für das Testen und

die Überarbeitung der Dokumentation ist kein Risiko zu vermerken, da dort auf

vorgefertigte und erprobe Abläufe zurückgegriffen werden kann.

In Summe hat dieses Projekt einen Risikoschaden von 21 Stunden. Werden diese auf

die 308 Stunden addiert, welche aus der Schätzung entstanden sind, wird eine Summe

Beschreibung Zusatz Risiko Prozent Risiko Puffer

Vorarbeit 20 20% 4

Modellierung Prozess 48 30% 14,4

Pflege Beziehungswissen 2 25% 0,5

Pflegeoberfläche ob Bezw da 1 25% 0,3

Pflege Tabelle ob Bezw da 0 25% 0,04

Webserve ob Bezw da 1 25% 0,3

Verteilung 0 25% 0,1

Anpassung UI 2 25% 0,45

Webservice Bezw 2 25% 0,6

Testing

Doku überarbeiten

Projektmanagement (10%)

Stunden 21

Tage 41,0

Evaluation


47

von 239 Stunden, was 41 Personentagen entspricht. Dies würde bei einem Stundensatz

von je 100€ Projektkosten in Höhe von circa 32.800€ bedeuten.

4.3.4 Ansatz Vier

Der Aufwand für Ansatz vier variiert ein wenig von Ansatz drei, da der externe

Mitarbeiter die Vorarbeit übernehmen könnte. Dadurch muss er Teil des Teams sein,

welches den Prozess modelliert. Ebenso kann er die Pflegeoberfläche für das PC, in

welcher eingetragen werden kann, welches Beziehungswissen für den Endress+Hauser

Konfigurator relevant ist, übernehmen. Die Webservices zum Überprüfen, ob

Beziehungswissen vorhanden ist, und zum Ausführen des Beziehungswissens, können

ebenso von dem externen Mitarbeiter übernommen werden. Zum Abschluss ist es des

Weiteren möglich, die Dokumentationsanpassung von ihm erledigen zu lassen. Da ein

externer Mitarbeiter meistens mit mehr Projektmanagementaufwand verbunden ist,

und die Risiken sich an manchen Stellen verändern folgt nachfolgend die Auflistung der

Modifizierungen und die erneute Berechnung des Aufwandes in der nachfolgenden

Tabelle:

Durch die Erhöhung des Projektmanagementzeitaufwands von zehn Prozent auf 15%

erweitert sich der Aufwand auf 41 Stunden. Bezüglich der Risiken ist ein Anstieg der

Eintrittswahrscheinlichkeit von 20% auf 40% bei der Aufwendung von zusätzlichen 20

Stunden realistisch. Somit besteht ein Risikoschaden von 8 Stunden.

Tabelle 4 - Aufwandsschätzung Ansatz 4

Anschließend ist eine Anpassung der Risiken nötig. Daher folgen die Tabelle der

Berechnung und die Erläuterung.

Beschreibung Faktor IS Faktor Extern Fatkor PC Faktor SC Faktor OIO Aufwand Summe IS Summe Extern Summe PC Summe SC Summe OIO Gesamt

Vorarbeit 1,00 40 0 40 0 0 0 40

Modellierung Prozess 3,00 1,00 1,00 1,00 8 24 8 8 8 0 48

Pflege Beziehungswissen 10,00 2 0 0 20 0 0 20

Pflegeoberfläche ob Bezw da 1,00 12 0 12 0 0 0 12

Pflege Tabelle ob Bezw da 10,00 0 0 0 2 0 0 2

Webserve ob Bezw da 1,00 12 0 12 0 0 0 12

Verteilung 1,00 4 0 4 0 0 0 4

Anpassung UI 1,00 2,00 6 6 0 0 0 12 18

Webservice Bezw 1,00 24 0 24 0 0 0 24

Testing 3,33 2,67 1,00 12 40 0 32 12 0 84

Doku überarbeiten 1,00 16 0 16 0 0 0 16

Projektmanagement (15%) 42 42

Stunden 112 116 62 20 12 322

Tage 14 15 8 3 2 40

Gesamtkosten 100,00 € 125,00 € 100,00 € 100,00 € 100,00 € Betrag 11.195,00 € 14.500,00 € 6.166,67 € 2.000,00 € 1.200,00 € 35.061,67 €

Evaluation


48

Tabelle 5 - Risikobewertung Ansatz 4

Durch die Teilnahme eines externen Mitarbeiters erhöht sich bei der

Prozessmodellierung das Risiko auf Grund der Möglichkeit der ungenauen

Vorbereitung um fünf Prozentpunkte. Dadurch erhöht sich der Risikoschaden auf 16,8

Stunden. Wird nun die Summe der benötigten Stunden für diesen Ansatz betrachtet,

so ist ersichtlich, dass 349 Stunden Arbeit fällig sind, was 43,3 Personentagen

entspricht. Unter Berücksichtigung, dass der externe Mitarbeiter mit einem

Stundensatz von 125€ arbeitet, ist somit ein Betrag von circa 38.000€ nötig, um dieses

Projekt zu finanzieren.

4.4 Auswahl

Werden die Anforderungen betrachtet, kommen ausschließlich Ansatz drei und vier in

Frage, da Ansatz eins keine funktionierende Lösung bieten konnte. Des Weiteren kann

Ansatz zwei nicht in einem definierten Anfangs- und Endtermin abgewickelt werden

sondern bedarf dauerhafter Betreuung durch Endress+Hauser InfoServe. Des Weiteren

ist eine Diskrepanz der Gesamtkosten der Ansätze drei und vier von 5.000€ zu

erkennen. Dadurch hat Ansatz drei eine bessere Ausgangslage und werden zusätzlich

noch die Eintrittswahrscheinlichkeiten der Risiken bei Ansatz drei und vier betrachtet,

fallen diese bei Ansatz drei wesentlich geringer aus.

Beschreibung Zusatz Risiko Intern Zusatz Risiko Extern Prozent Risiko Puffer Intern Puffer Extern

Vorarbeit 20 40% 0 8

Modellierung Prozess 40 8 35% 14 2,8

Pflege Beziehungswissen 2 25% 0,5 0

Pflegeoberfläche ob Bezw da 1 25% 0 0,3

Pflege Tabelle ob Bezw da 0 25% 0,04 0

Webserve ob Bezw da 1 25% 0 0,3

Verteilung 0 25% 0 0

Anpassung UI 2 25% 0,45 0

Webservice Bezw 2 25% 0 0,6

Testing

Doku überarbeiten

Projektmanagement (15%)

Stunden 15 12

Tage 1,9 1,5

Zusatzkosten 1.499,17 € 1.500,00 €

Das Projekt


49

5 Das Projekt

5.1 Projektablauf

Um den Ablauf des Projektes anschaulich darzustellen ist in Abbildung 11 ein Netzplan

zu sehen, welcher die einzelnen Aufgaben und ihre Abarbeitungsreihenfolge darstellt.

In diesem Kapitel wird davon ausgegangen, dass die Aufwandsschätzung aus dem

vorherigen Kapitel korrekt ist und keine Risiken eintreten. Ebenso werden weitere

Aufwände wie Datenpflege im laufenden Betrieb nicht mit berechnet, da diese für

dieses Projekt nicht relevant ist und zum aktuellen Zeitpunkt auch schon von den PCs

ausgeführt wird. Somit ist die Datenpflege durch das Projekt von keiner Veränderung

betroffen. Die im Folgenden beschriebenen Vorgänge sind in der Abbildung 11

graphisch dargestellt. Zur Erläuterung der Abbildung folgt eine Legende.

Tabelle 6 - Legende Netzplan

Die nachfolgende Umsetzung des Ansatzes geschah in einer Sandbox Umgebung eines

SAP Systems, um so die Realität bestmöglich abbilden zu können. Dabei wurde

ausschließlich ein Produkt betrachtet, welches mit der Problematik die bereits in

Kapitel Vier erläutert wurde, behaftet ist. Beginnend mit der Vorarbeit startet das

Projekt mit der Arbeit eines Experten im SAP Umfeld, um die nötigen Informationen

für Vorgang zwei zu sammeln. In diesem wird der neue Prozess, durch den Einsatz des

SAP Beziehungswissens, im Endress+Hauser Konfigurator 6.0 definiert. Da Vorgang

zwei auf Vorgang eins aufbaut, und bei nicht Einhalten der geplanten Zeit für Vorgang

eins Vorgang zwei zeitlich nach hinten verschoben würde, ist dies der Beginn des

kritischen Pfades. Nach der Modellierung des Prozesses folgen fünf parallele Vorgänge,

FAZ FEZ

Nr.

D GP FP

SAZ SEZ

Name

Das Projekt


50

welche alle von unterschiedlichen Personen bearbeitet werden und nicht aufeinander

aufbauen. Ebenso wurde in Vorgang zwei genau definiert, welche Schnittstellen und

Anpassungen an der Benutzeroberfläche vorgenommen werden müssen, damit die

Parallelisierung ohne Schwierigkeiten durchführbar ist.

In Vorgang drei und dem darauf folgenden Vorgang werden zuerst die Tabellen,

welche zur Pflege der Information, ob zu diesem Produkt ein Beziehungswissen

vorhanden ist, erstellt und anschließend die dazugehörigen Pflegeoberflächen. In

Vorgang fünf wird der entsprechende Webservice entwickelt, der zur Nutzung der

soeben erstellten Tabelle genutzt wird. In Vorgang sechs wird vom PC Wetzer das

Beziehungswissen für die Produkte gepflegt und auf seine Richtigkeit geprüft. In den

Vorgängen sieben und acht werden die Anpassungen an der Benutzeroberfläche zuerst

von interner und anschließend von externer Seite bearbeitet. In Vorgang neun wird

das Kernstück dieses Projektes entwickelt:

Der Webservice zur Validierung der Konfiguration durch das SAP Beziehungswissen.

Auf Vorgang neun folgen erneut drei parallele Vorgänge. In diesen werden von

unterschiedlichen Personengruppen die angepassten Änderungen getestet. Darauf

folgt noch die Anpassung der Dokumentation in Vorgang 13.

Wird der kritische Pfad dieses Netzplans betrachtet, ist zu sehen, dass ausschließlich

fünf Vorgänge Spielraum in ihrem Umsetzungszeitraum besitzen. Dies ist kein Problem,

da die Aufgaben auf dem kritischen Pfad alle von InfoServe Mitarbeitern bearbeitet

werden, die sehr eng miteinander zusammen arbeiten, was mögliche Verzögerungen

ausgleichen kann und dadurch die Einhaltung des Endtermins sichern kann.

Das Projekt


51

Abbildung 11 - Netzplan zum Projektablauf

Das Projekt


52

5.2 Entwicklung

Durch die Vorgabe, das vorhandene SAP Beziehungswissen zu nutzen, war es nötig,

eine Ansatzstelle im vorhandenen SAP Programm zu finden, welche genutzt werden

kann, um das SAP Beziehungswissen aufzurufen. Die Suche nach dieser Ansatzstelle

erwies sich als schwieriger als gedacht und eine detaillierte Beschreibung würde den

Rahmen dieser Arbeit sprengen. Stark vereinfacht wird eine Konfiguration im SAP

Konfigurator simuliert, in welchem das SAP Beziehungswissen abgearbeitet wird. Das

Finden dieser Stelle implizierte den Abschluss der Vorarbeit und die Modellierung des

Prozesses konnte beginnen. Als Produkt eines Meetings mit den Verantwortlichen des

bisherigen Konfigurationsprozesses ergab sich der im nachfolgenden Kapitel sichtbare

Prozess. Im Unterschied zum bisherigen Ablauf des Bestellprozesses wird dabei bereits

während der Konfiguration validiert, ob die gewählte Konfiguration des Kunden

technisch umsetzbar ist.

Da nun bekannt ist, an welcher Stelle der Konfiguration eine Validierung stattfinden

soll, ist es die Aufgabe des PC Wetzers die gewünschten Produkte mit dem nötigen

Beziehungswissen auszustatten, um eine solche Validierung zu ermöglichen. In den

meisten Fällen war dieses Wissen schon vorhanden, da es bereits zur Ableitung der

Konfiguration aus der Bestellung des SCs genutzt wird. Allerdings ist es nötig, es auch

im SAP System der SCs zur Verfügung zu stellen, da sonst eine Validierung im Online-

Shop nicht möglich wäre.

In einem weiteren Schritt wurde eine Pflegeoberfläche im SAP geschaffen, in der das

PC Wetzer für das Beziehungswissen von jedem einzelnen Produkt hinterlegen kann,

welches Wissen zur Validierung genutzt werden soll. Für diese Pflegeoberfläche ist

eine Verteilung der gepflegten Daten notwendig, da sonst Konfigurationen nicht

durchgängig valide sind. Ansonsten könnte es zu Laufzeitfehlern während der

Validierung kommen, da auf nicht vorhandene Daten referenziert wird.

Der nächste Schritt war die Anpassung des Webservices, der alle notwendigen Daten

zu einem für die Konfiguration ausgewählten Produkt zur Verfügung stellt. Dieser

Webservice musste um die Information, ob es Beziehungswissen zum Validieren gibt

oder nicht, erweitert werden. Dafür bedurfte es einer Strukturerweiterung des

Das Projekt


53

Webservices, damit weitere Parameter übergeben werden können und einer

Erweiterung der XML Struktur und die eigentliche Anpassung am Webservice.

Anhand dieser Vorgaben wurde die Oberfläche, wie in der folgenden Abbildung zu

sehen ist, angepasst. Dabei ist es nötig, einen Validierungsknopf anzuzeigen, falls

Beziehungswissen vorhanden ist. Dieser Knopf ruft den Webservice zur Validierung auf

und soll anschließend anzeigen, ob die Validierung erfolgreich war, also ob die

Konfiguration valide ist und das Produkt der Bestellung hinzugefügt werden kann, oder

ob die Konfiguration fehlerhaft ist und somit eine Anpassung nötig ist.

Abbildung 12 - Validierung der Konfiguration durch SAP Beziehungswissen62

Der für diesen Schritt nötige Webservice bedarf einer neuen Request und Response

Struktur mit dementsprechenden XML Dateien, der Entwicklung des Webservices und

eines Testprogramms. Letzteres ist vorgeschrieben, um den Webservice im

Produktivsystem von Endress+Hauser einsetzen zu dürfen. Die Vorgabe ist, dass das

Testprogramm, welches alle neu implementierten Funktionen testet, mindestens

einmal erfolgreich durchlaufen werden muss, bevor eine Verteilung in das

Produktivsystem möglich ist. Diese Aktivierung ist aus Sicherheitsgründen nur durch

wenige Personen möglich, da bei Übertragung von fehlerhafter Software

62

Screenshot des Endress+Hauser Konfigurators 6.0 mit kleinen Veränderungen

Das Projekt


54

beispielsweise der Endress+Hauser Konfigurator nicht mehr verfügbar sein könnte.

Dies könnte dazu führen, dass keine neuen Bestellungen mehr möglich sind und somit

das Kerngeschäft von Endress+Hauser stark beeinträchtigt sein könnte. Daher ist das

Testen der entwickelten Applikation notwendig. Endress+Hauser InfoServe nutzt dafür

ein Tool, mit welchem Testfälle definiert werden können, welche von unabhängigen

Testern durchgeführt werden.

Zum Schluss ist eine Anpassung der Dokumentationen nötig, welche die Konfiguration

betreffen, da bei weiteren Anpassungen oder Optimierungen auf diese zurückgegriffen

wird.

5.3 Der neue Ablauf

In der folgenden Abbildung ist der neue Bestellprozess dargestellt. Der größte

Unterschied ist die Verschiebung der ‚Prüfung auf technische Umsetzbarkeit der

Konfiguration‘ von der manuellen Arbeit in die automatisierte Arbeit des

Endress+Hauser Konfigurators 6.0. Somit erhält der Kunde direkt Feedback, wenn die

ausgewählte Konfiguration technisch nicht umsetzbar ist.

Stark vereinfacht wird, wie in der nachfolgenden Abbildung sichtbar ist, unabhängig

vom System, aus welchem der Endress+Hauser Konfigurator 6.0 aufgerufen wird,

immer der gleiche Prozess durchlaufen. Mit dem Aufruf werden einige

Basisinformationen wie das Produkt und die zu konfigurierende Stückzahl mit

übergeben. Anschließend ruft der Konfigurator mehrere Webservices auf, welche alle

Informationen für die Konfiguration laden. Nun ist es möglich, ohne weiteren Aufruf

von Webservices die komplette Konfiguration durchzuführen. Neu hinzugekommen ist

nun, dass am Ende der Konfiguration die Validierung über das SAP Beziehungswissen

möglich ist. Sobald dies geschehen ist, ist die Konfiguration valide und wird als

‚item.xml‘ zurück an das rufende System gegeben um dort weiter verarbeitet zu

werden.

Das Projekt


55

Pricing Engine

Deliv.Time

Engine

E+H Configurator Version 6

Basic Configuration

TaggingNew TSP

Alter-native

Measurement Rucksack

Rucksack Validation

Ident

BasicConf.

MData

IdentInquiry

TAGMData

TSPMData

Ruck-sack

MData

Ruck-sack

Valid.

PMDCorresponding ERP System

Web Services

Item.xmlProduct

CRM

SHOP PEA

SAP Dep. Validation

SAP Depen-dencyValid.

ERP

Abbildung 13 - Technischer Ablauf der Konfiguration63

Durch die Anpassung des Prozesses ist es zudem möglich, im PC keine erneute Prüfung

durchzuführen, was für das PC eine enorme Zeitersparnis bedeutet, da die

Produktverantwortlichen nicht bei jeder Konfiguration, welche ein technisches

Problem beinhaltet, erneut Kontakt mit dem Kunden aufnehmen müssen. Alles in

allem wird somit die manuelle Arbeit automatisiert.

63

Eigendarstellung

Das Projekt


56

Abbildung 14 - Neuer Bestellprozess via Online Shop64

64

Eigendarstellung nach (Frey, 2015)

Zurück in die Zukunft


57

6 Zurück in die Zukunft

6.1 Vergangenheit

Zusammenfassend wird erneut die Ausgangssituation betrachtet, in welcher nach

einer Konfiguration des Kunden das Sales Center die Bestellung überprüft und

anschließend an das verantwortliche Product Center weiter geleitet hat, welches auf

Basis der kundenspezifischen eine technische Konfiguration abgeleitet hat. Mit dieser

technischen Konfiguration war es möglich, mit Hilfe des SAP Beziehungswissens zu

analysieren, ob die Konfiguration umsetzbar ist oder nicht.

Wird die Idee, diesen Schritt der Validierung bereits während der Konfiguration zu

durchlaufen, nur oberflächlich betrachtet, erscheint sie banal. Wird allerdings dieses

Thema genauer beleuchtet, spielen einige wichtige und komplexen Systeme und

Bausteine der SAP- und Endress+Hauser Welt eine wichtige Rolle, welche alle bedacht

werden müssen.

Eine der anspruchsvollsten Aufgaben war es, eine Schnittstelle für den Webservice zu

finden, welcher aus dem Konfigurator aufgerufen werden kann um das SAP

Beziehungswissen aufzurufen, zu finden.

Eine weitere Herausforderung war ebenso, dass es nicht ohne Probleme möglich war

eine Konfiguration aus dem Endress+Hauser Konfigurator 6.0 ohne Probleme in einem

SAP System des Sales Center zu validieren, da dort einige Daten nicht vorhanden

waren, die für diesen Vorgang nötig gewesen wären.

Die Lösung für dieses Problem war die Pflege der Daten in einer bereits vorhandenen

zentralen Datenbank und anschließende Verteilung in die SAP Systeme der Sales

Center und Product Center.

Alle weiteren Schritte waren für die Umsetzung kein großes Hindernis mehr, da dies

Tätigkeiten waren, welche bereits bei der Entwicklung des Konfigurators bereits einige

Male von Endress+Hauser InfoServe umgesetzt wurden.



58

Mit der Integration des SAP Beziehungswissens in den SAP Konfigurator hat der Kunde

nun die Gewissheit, dass sein Produkt keine technischen Schwierigkeiten bei der

Umsetzung aufweisen wird. Es ist natürlich nicht auszuschließen, dass bei der Pflege

durch die Product Center Fehler gemacht werden und dadurch das in der

Konfiguration abgebildete Produkt in Realität nicht umgesetzt werden kann.

Da das gesamte Projekt ausschließlich in einer Sandbox Umgebung und mit stark

eingeschränktem Umfang der Produkte umgesetzt und getestet wurde ist nicht

garantiert, dass bei einer Umsetzung in den Produktivsystemen der Endress+Hauser

Gruppe keine Probleme auftreten.

Des Weiteren ist fraglich, ob das Projekt für die komplette Endress+Hauser Gruppe

überhaupt umgesetzt wird, da zum aktuellen Zeitpunkt nur ein Product Center daraus

einen Vorteil ziehen könnte. Da allerdings alle Product Center für ein Gruppenprojekt

dieser Größe finanzielle Mittel zur Verfügung stellen müssten, ist eine Umsetzung nicht

realistisch.

Alles in Allem ist es möglich das SAP Beziehungswissen in die Eigenentwicklung, den

Endress+Hauser Konfigurator 6.0, zu integrieren. Es bedarf allerdings einer genauen

Betrachtung der Vorteile für die Product Center, die Sales Center und natürlich den

Kunden um den mit der Entwicklung verbundenen Aufwand zu rechtfertigen.

6.2 Zukunft

Im Folgenden werden einige als realistisch betrachtete Ereignisse, welche den

Endress+Hauser Konfigurator 6.0 und allgemein die Produktvielfalt betreffen,

beschrieben. Ebenso wird betrachtet, welche Faktoren zu einer drastischen

Veränderung im Konfigurationsumfeld beitragen könnten.

Als eines der nächsten Projekte bei Endress+Hauser InfoServe könnte somit zum

Beispiel die Erweiterung des Konfigurators mit grafischen Elementen sein. Es könnte

sich dabei um technische Zeichnungen oder auch eine grafische Ansicht des aktuell

konfigurierten Produkts, wie es zum Beispiel im Konfigurator in der folgenden

Abbildung des Automobilherstellers Tesla der Fall ist, handeln.



59

Abbildung 15 - Ausschnitt des grafischen Konfigurators des Automobilherstellers Tesla65

Der Kunde hat somit die Möglichkeit, die Änderung seiner Konfiguration direkt an

seinem Produkt zu sehen, und kann dieses auf seine bisherigen Produkte abstimmen

oder sich manche Besonderheiten besser vorstellen.

Des Weiteren könnte es vorstellbar sein, dass es bald eine neue Version des Offline

Konfigurators geben wird. Die aktuell veröffentlichte Version wird einmal im Jahr per

DVD verschickt und enthält somit nur die zu diesem Zeitpunkt aktuellen Produkte,

Preise, Ausschlüsse und vieles mehr. Allerdings werden im Laufe des Jahres sehr oft

Anpassungen an den Preisen oder den Ausschlüssen vorgenommen, was somit beim

Bestellen der im Offline Konfigurator erstellten Konfiguration, zu Problemen führen

kann, da sich ein Preis für ein Produkt verändert hat oder ein neuer Ausschluss auf ein

Merkmal oder eine Merkmalswertkombination erstellt wurde.

Eine mögliche Umsetzung wäre dabei, eine installierbare Version des Endress+Hauser

Konfigurators 6.0 zu entwickeln, welcher als Fundament eine lokale Datenbasis nutzt.

Diese Datenbasis kann lokal auf dem Rechner gespeichert werden, um so eine

erfolgreiche Konfiguration auch ohne Internetzugang zu gewährleisten.

65

Screenshot von (Tesla, 2015)



60

Als IT-Dienstleister für die Endress+Hauser Gruppe ist es, wie bereits erwähnt, die

Aufgabe von Endress+Hauser InfoServe neue Trends, welche für Endress+Hauser einen

Vorteil gegenüber der Konkurrenz bringen, zu erkennen und auf diese aufzuspringen.

Einer dieser Trends ist die intensivierte Nutzung von mobilen Endgeräten. Diese

werden in der gesamten Endress+Hauser Gruppe bereits genutzt. Eine mögliche Idee

wäre daher, für Vertriebs- oder Servicemitarbeiter eine Installation des

Endress+Hauser Konfigurators auf einem Tablet vorzunehmen. Dies hätte den Vorteil,

dass der Kunde vor Ort sehen könnte, welche Konfiguration für sein Produkt möglich

ist oder nicht und der Vertriebsmitarbeiter ihm sofort mögliche Fragen beantworten

könnte. Wie in der nachfolgenden Abbildung zu sehen ist, könnte der aktuelle

Konfigurator vom Design sehr gut verwendet werden. Ebenso wie bei der auf dem

Computer installierbaren offline Version, sollte auch diese Version keine dauerhafte

Internetverbindung voraussetzen.

Abbildung 16 - Idee des mobilen Endress+Hauser Konfigurators66

66

Eigendarstellung mit Screenshot des aktuellen Endress+Hauser Konfigurators 6.0 und dem Apple iPad

Quellenverzeichnis


IX

Quellenverzeichnis

Printmedien

Bartuschat, M. (1995)

Beitrag zur Beherrschung der Variantenvielfalt in der Serienfertigung, Essen.

Blumöhr, U., Münch, M. und Ukalovic, M. (2013)

Variantenkonfiguration mit SAP, 2. Auflage, SAP Press.

Bongulielmi, L. (2003)

Die Konfigurations- & Verträglichkeitsmatrix als Beitrag zur Darstellung

konfigurationsrelevanter Aspekte im Produktentstehungsprozess, Düsseldorf.

Boysen, N. (2005)

Variantenfließfertigung, Wiesbaden.

Bräutigam, L.-P. (2004)

Kostenverhalten bei Variantenproduktion, Wiesbaden.

Bruhn, M. und Homburg, C. (2004)

Gabler Marketing Lexikon, 2. Auflage, Wiesbaden.

Caesar, C. (1991)

Kostenorientierte Gestaltungsmethodik für variantenreiche Serienprodukte: Variant

Mode and Effects Analyses (VMEA), Düsseldorf.

Capgemini (2010)

Welche Anforderung an Autoverkaufs-Webseiten sind Ihnen am wichtigsten?,

Statista.

Deutsches Institut für Normung (2002)

DIN 199, Teil 1: Technische Produktdokumentation-CAD-Modelle, Zeichnungen und

Stücklisten: Begriffe, Berlin.

Gembrys, S.-N. (1998)

Ein Modell zur Reduzierung der Variantenvielfalt in Produktionsunternehmen, Berlin.

Heina, J. (1999)

Variantenmanagement: Kosten-Nutzen-Bewertung zur Optimierung der

Variantenvielfalt, Wiesbaden.

Quellenverzeichnis


X

Jones, C. (2008)

Estimating Software Costs, 2. Auflage, McGrawHill.

Kohlhase, N. (1997)

Strukturieren und Beurteilen von Baukastensystemen: Strategie, Methoden,

Instrumente, Düsseldorf.

Korreck, A. (2002)

Methodik zur markt- und kostenorientierten Variantenplanung, Aachen.

Kühl, S. (2009)

Handbuch Methoden der Organisationsforschung, P.S.A.T.

Lingnau, V. (1994)

Variantenmanagement: Produktionsplanung im Rahmen einer

Produktionsdifferenzierungsstrategie, Berlin.

Mangold, P. (2009)

IT-Projektmanagement kompakt, 3. Auflage, Spektrum Akademischer Verlag.

MeinAuto.de und JATO (2013)

Top 10 Automobilhersteller auf dem deutschen Markt nach der Anzahl der

Modellvarianten, Statista.

Menge, M. (2001)

Ein Beitrag zur Beherrschung der Variantenvielfalt in der auftragsbezogenen Einzel-

und Kleinserienfertigung komplexer Produkte, Essen.

Noosten, D. (2013)

Netzplantechnik, Springer.

Rapp, T. (1999)

Produktstrukturierung: Komplexitätsmanagement durch modulare Produktstrukturen

und -plattformen, Wiesbaden.

Rosenberg, O. (1996)

Variantenfertigung, in: Kern, W. /Schröder, H.-H./Weber, J.: Handwörterbuch der

Produktionswirtschaft, Sp. 2119-2129, 2. Auflage, Stuttgart.

Seidlmeier, H. (2015)

Prozessmedllierung mit ARIS, 4. Auflage, Wiesbaden: Springer.

Quellenverzeichnis


XI

Silver, Bruce (2012)

BPMN Methoden und Stil, 2. Auflage, Cody-Cassidy Press.

Souren, R. (1996)

Theorie betrieblicher Reduktion: Grundlagen, Modellierung und Optimierungsansätze

stofflicher Entsorgungsprozesse, Heidelberg.

Verein Deutscher Ingenieure (1978)

Elektronische Datenverarbeitung bei der Produktionsplanung und -steuerung VI:

Begriffszusammenhänge, Begriffsdefinitionen, 2. Auflage, Düsseldorf.

Wack, J. (2006)

Risikomanagement für IT-Projekte, Hamburg.

Firmenquellen

Diemer, B. (2015)

Interview über Integration des SAP Beziehungswissens in den E+H Konfigurator aus

der Sicht des PC Wetzers.

Eichkorn, C. (2015)

Interview über Integration SAP Beziehungswissen in den E+H Konfigurator.

Endress+Hauser (2015)

Endress+Hauser Wetzer, [Online], in: http://www.endress.com/de/Endress-Hauser-

Gruppe/product-center-competencies/Endress+Hauser-Wetzer-Nesselwang [07 Aug

2015].

Endress+Hauser (2015)

Portrait, Rheinach.

Endress+Hauser Gruppe (2014)

Geschäftsbericht, in:

http://www.de.endress.com/eh/sc/europe/dach/de/home.nsf/#page/~zahlen-und-

fakten [09 September 2014].

Endress+Hauser InfoServe (2015)

Endress+Hauser InfoServe, IT Partner der E+H Gruppe, 01 Jul, S. 2.

Quellenverzeichnis


XII

Endress+Hauser Messtechnik GmbH (2015)

Die Endress+Hauser Messtechnik GmbH, Ihr Vertrieb und Service in Deutschland, 09

March, S. 2.

Endress+Hauser Wetzer (2014)

Endress+Hauser Wetzer, Nesselwang.

Frey, F. (2015)

Modellierungsmeeting für die Integration von SAP Beziehungswissen in den E+H

Konfigurator, Weil am Rhein.

Lauke, M. (2015)

Interview über Integration von SAP Beziehungswissen in den E+H Konfigurator.

Webseiten

Tesla, D.M. (2015)

Design Studio Model S, September, [Online], in:

http://my.teslamotors.com/de_DE/models/design [07 September 2015].

Anhang


XIII

Anhang

Interview mit Hr. Lauke – Verantwortlicher für den E+H Konfigurator

Guten Mittag. Ich schreibe meine Bachelorarbeit über die Integration von SAP Beziehungswissen in

den E+H Konfigurator. Mein Ziel ist es zu erreichen, dass dem Kunden noch während der

Konfiguration mitgeteilt werden kann, ob seine Konfiguration so im PC umgesetzt werden kann.

Guten Tag. In der Tat, das wäre eine wichtige Verbesserung.

Deswegen werde ich einige Ansätze recherchieren und am Schluss den Aufwand für diese Ansätze zu

berechnen. Welcher Ansatz soll gewählt werden, wenn die Aufwände gleich hoch sind und sich

ausschließlich die Risiken unterscheiden?

Dann wählen Sie den Ansatz, der mit dem geringsten Risiko verbunden ist.

Welche Kriterien sind für Sie dabei am Wichtigsten?

Mir ist sehr wichtig, dass wir durch die Implementierung der Idee keinen permanenten Mehraufwand

haben, sondern einmal, in Form eines Projekts, die Integration durchführen können und

anschließend die PCs die Pflege übernehmen können.

Einer der Ansätze, die ich in der Arbeit behandeln werde ist der, eine externe Firma zu beauftragen,

eine solche Lösung zu entwickeln. Was meinen Sie dazu?

Ich denke dies wäre sehr gut, allerdings bezweifle ich, dass wir eine solche Firma finden können.

Ebenso frage ich mich, ob dies sinnvoll wäre, da wir selbst die Mittel und das Wissen hätten, diese

Aufgabe umzusetzen.

Anhang


XIV

Interview mit Christine Eichkorn – SAP Expert und Entwicklerin am E+H Konfigurator

Wie viele der Endress+Hauser Produkte sind konfigurierbar?

Es sind etwa 9.000 mit insgesamt 75.620 Merkmalen, aus denen der Kunde wählen kann.

Und wie viele Kombinationen ergibt das insgesamt pro Produkt?

Das sind 531.441.

Wie kommen Sie auf diese Zahlen?

Nun ja, ein Produkt hat durchschnittlich um die neun Merkmale und sechs verschiedene

Ausführungen. Da den 75.620 Merkmalen 449.403 Merkmalswerte zugeordnet werden können,

kommt man auf diese Zahl.

Das sind dann insgesamt um die vier Milliarden Kombinationsmöglichkeiten, ist das richtig.

Ja, das ist richtig.

Können Sie mir den aktuellen Prozess, wie ein Kunde ein Produkt bei Ihnen bestellen kann, erklären?

Sehr gerne. Unser Kunde kann dabei zum Beispiel aus dem Online Shop ein Produkt auswählen, die

Menge spezifizieren und anschließend die Konfiguration im E+H Konfigurator durchführen.

Anschließend werden alle konfigurierten Produkte an das SC gesendet, welche eine oberflächliche

Prüfung der Bestellung vornehmen. Der Mitarbeiter des SC erstellt anschließend einen

Produktionsauftrag für das entsprechende PC. Das PC leitet anschließend von der vom SC erhaltenen

Konfiguration die für sie zusätzlich relevanten Merkmale mit Hilfe von SAP Beziehungswissen ab und

prüft diese auf die technische Umsetzbarkeit. Wird dabei ein Konflikt entdeckt, wird der Kunde

kontaktiert, welcher dann die nötigen Änderungen genehmigen muss, um die Produktion zu starten.

Falls kein Konflikt vorliegt, geschieht dies direkt.

Ich würde gerne für das Projekt eine Aufwandsschätzung durchführen und bräuchte dabei Ihre

Erfahrungswerte.

Ja, da kann ich Ihnen helfen.

Sehr gut. In meiner Arbeit beschreibe ich einen Ansatz, bei dem das SAP Beziehungswissen

nachentwickelt werden soll. Wie hoch schätzen Sie den Aufwand für die Entwicklung eines

Webservices, des SAP Funktionsbausteines und für die Eintragung in eine Pflegetabelle?

Ich würde einen Aufwand von etwa zwei Personentagen rechnen. Mit wie vielen Produkten im Jahr

du allerdings rechnen solltest, weiß ich nicht. Zusätzlich kommen noch ungefähr zwei Personentage

Anhang


XV

hinzu, die benötigt werden, um die Pflegemaske und die Merkmalstabelle im jeweiligen Webservice

zu speichern.

Der nächste Ansatz, den ich behandeln werde basiert darauf, das SAP Beziehungswissen per

Webservice aus dem E+H Konfigurator zu validieren. Dabei wird die genaue technische Überprüfung

und Machbarkeitsanalyse anfallen, der Prozess muss modelliert werden das Beziehungswissen muss

im SAP eingepflegt werden. Meist ist dies schon der Fall, allerdings werden einige Produkte neu

eingepflegt werden müssen. Des Weiteren muss eine Pflegeoberfläche zur Verfügung gestellt werden,

die testet, ob das Produkt über SAP Beziehungswissen validiert werden muss. Wie schätzen Sie den

Aufwand für die Schritte bis hier hin?

Für die Vorarbeit, also die Überprüfung und Analyse sollten etwa 40 Stunden gerechnet werden. Für

die Modellierung würde ich 4 InfoServe Mitarbeiter und 1 PC Wetzer Mitarbeiter für je acht Stunden

einplanen.

Ich würde sagen, dass 10 Produkte noch in die CDB eingepflegt werden müssen. Bei zwei Stunden

pro Produkt ergibt dies 20h plus 10min pro Produkt, die das PC Wetzer zur Einpflege aufwenden

muss. Die Pflegeoberfläche wird weiter 12h in Anspruch nehmen und die Verteilung in die Systeme

der Sales und Product Center benötigt weitere 4 Stunden.

Neben der Pflege muss bei diesem Ansatz auch ein Webservice zur Überprüfung programmiert

werden. Wie lange schätzen Sie den Aufwand hierfür?

Hierfür würde ich 12 Stunden rechnen.

Der nächste Schritt wäre es, die Benutzeroberfläche des Konfigurators anzupassen, was in

Zusammenarbeit mit einem externen Partner geschieht. Hier wird ein Webservice zum Aufrufen des

Wissens eingerichtet werden müssen, der die Konfiguration validiert.

Der externe Angestellte benötigt für seine Arbeit 12h Zeit. Zusätzlich sollten aber weiter 6h Zeit für

das InfoServe Team gerechnet werden.

Um den Webservice zu implementieren wird vermutlich 24h benötigt.

Und wie viel Zeit sollte ich für das Testing rechnen?

40h für InfoServe, 32h für das PC Wetzer und 12h für das SC.

Die Projektplanung sollte natürlich auch nicht vernachlässigt werden.

Richtig. Bei unseren bisherigen Projekten haben wir dabei immer mit pauschal zehn Prozent des

Gesamtaufwandes gerechnet, also 28 Stunden.

Anhang


XVI

Okay, zusätzlich zu meiner Aufwandsschätzung würde ich Sie gerne fragen, wie hoch ich die

jeweiligen Risikowerte ansetzen sollte.

Nun ja, dass die Vorarbeit nicht zufriedenstellend ausgeführt wird und wir an dieser Stelle 20h mehr

einplanen müssen liegt bei 20%.

Und was ist mit der Planung und Modellierung? Hier wird doch bei drei unterschiedlichen Parteien

sicher Zeit verloren gehen?

Ja, das ist richtig. Das Risiko für acht weitere Stunden würde ich auf 30% ansetzen. Zudem sollte das

Risiko bedacht werden, dass bei Entwicklungsaufgaben immer eine gewisse Unsicherheit besteht,

deshalb rechne hier mit 25% für weitere 10% der bereits berechneten Entwicklungszeit.

Wenn ich nun in meinem nächsten Ansatz einen externen Mitarbeiter hinzuziehe, wie viel

Mehraufwand muss ich für die Projektplanung und Steuerung rechnen?

Hier fallen ca. 5% mehr Aufwand an. Wenn dieser Mitarbeiter die Vorarbeit übernimmt, sollte für die

zusätzlichen 20h mit 40 statt 20% Eintrittswahrscheinlichkeit gerechnet werden.

Anhang


XVII

Interview mit Fr. Diemer – Produktmanager des PC Wetzers

Guten Tag. Ich schreibe meine Bachelorarbeit über eine mögliche Verbesserung des Endress+Hauser

Konfigurators 6.0. Welche Verbesserungen würden Sie sich an dieser Stelle wünschen?

Nun ja, es wäre wichtig, dass dem Kunden direkt bei der Konfiguration mitgeteilt wird, ob seine Wahl

im PC umsetzbar ist. Dies wäre für alle Parteien eine enorme Verbesserung.

Ich gedenke im Rahmen dieser Verbesserung den Ansatz durchzudenken, ob das SAP

Beziehungswissen im E+H Konfigurator nachgebaut werden kann. Um den Aufwand hierfür

abzuschätzen müsste ich wissen, mit wie vielen Produkten ich jährlich rechnen sollte.

Ich denke 10 Produkte im Jahr trifft es ungefähr, wobei ausschließlich eines das in Ihrer Arbeit

bearbeitete Rechentool benötigen würde.

Anhang


XVIII

Meetingprotokoll – Protokollant: F. Frey

Modellierung des neuen Bestellprozesses an Hand einer Bestellung über den Online Shop

1. Kunde besucht den Online Shop

2. Er wählt das gewünschte Produkt und Menge aus

3. Er führt die Konfiguration mit dem E+H Konfigurator 6.0 durch

4. Vor dem Hinzufügen des Produkts in den Warenkorb wird die Konfiguration überprüft

a. Dabei wird das SAP Beziehungswissen genutzt um die technische Umsetzbarkeit zu

gewährleisten

5. Anschließend wird die Bestellung abgesandt

6. Das SC prüft diese oberflächlich und erstellt ein Produktionsauftrag beim PC

7. Das PC leitet die nötigen Merkmalswerte, die sie für die Produktion benötigen ab und

beginnen mit der Produktion

Documents

Integration von SAP Beziehungswissen in den Endress+Hauser ... · Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator Bachelorarbeit für die Prüfung zum Bachelor