Integration von SAP Beziehungswissen in den Endress+Hauser ... · Integration von SAP...
Transcript of Integration von SAP Beziehungswissen in den Endress+Hauser ... · Integration von SAP...
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
I
Ehrenwörtliche Erklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit mit dem Thema
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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.
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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.
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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)
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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)
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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 Vgl. (Eichkorn, 2015)
5 Vgl. (Eichkorn, 2015)
6 Vgl. (Eichkorn, 2015)
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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.
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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. 2 16
Vgl. (Endress+Hauser InfoServe, 2015), S. 2 17
Vgl. (Endress+Hauser InfoServe, 2015), S. 1
Stammdaten
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Screenshot des Endress+Hauser Konfigurators 6.0
Der Wandel
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Screenshot des Endress+Hauser Konfigurators 6.0
Der Wandel
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Screenshot des Endress+Hauser Konfigurators 6.0
Der Wandel
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
35
Abbildung 8 - Bestellprozess via Online Shop53
53
Eigendarstellung nach (Eichkorn, 2015)
Der Wandel
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
39
Abbildung 9 - Omnigrad M TR1057
57
Endress+Hauser Mitarbeiter Portal Engine
Prozessanschluss
Halsrohr
Schutzrohr
Anschlusskopf
Gehäuse
Evaluation
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
51
Abbildung 11 - Netzplan zum Projektablauf
Das Projekt
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
56
Abbildung 14 - Neuer Bestellprozess via Online Shop64
64
Eigendarstellung nach (Frey, 2015)
Zurück in die Zukunft
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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.
Zurück in die Zukunft
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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.
Zurück in die Zukunft
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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)
Zurück in die Zukunft
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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
Integration von SAP Beziehungswissen in den Endress+Hauser Konfigurator
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